ECA Content hides core node action plugins during config import by aliasing FieldUpdateActionBase into ECA’s action interface
>>> [!note] Migrated issue
<!-- Drupal.org comment -->
<!-- Migrated from issue #3588862. -->
Reported by: [sam711](https://www.drupal.org/user/3561059)
Related to !620
>>>
<h3 id="summary-problem-motivation">Problem/Motivation</h3>
<p>When eca_content is enabled, fresh installs and browser tests can fail while importing core node action config such as system.action.node_promote_action.yml, system.action.node_unpromote_action.yml, system.action.node_make_sticky_action.yml, and system.action.node_make_unsticky_action.yml.</p>
<p>The failure happens because eca_content.module aliases <code>Drupal\Core\Field\FieldUpdateActionBase</code> to <code>Drupal\eca_content\Plugin\Action\FieldUpdateActionBase</code>. That ECA replacement base extends <code>Drupal\eca\Plugin\Action\ActionBase</code>, which implements<br>
<code>Drupal\eca\Plugin\Action\ActionInterface</code>. ECA’s decorated action manager then filters out any action plugin implementing that interface unless <code>externallyAvailable()</code> returns <code>TRUE</code>.</p>
<p>For node_promote_action, the chain is:</p>
<ul>
<li>Drupal imports system.action.node_promote_action.yml</li>
<li>The config points at plugin node_promote_action</li>
<li>Core defines that plugin as <code>Drupal\node\Plugin\Action\PromoteNode</code></li>
<li>PromoteNode extends <code>Drupal\Core\Field\FieldUpdateActionBase</code></li>
<li>eca_content.module aliases that base class to <code>Drupal\eca_content\Plugin\Action\FieldUpdateActionBase</code></li>
<li>The ECA replacement base inherits ActionInterface</li>
<li>ECA’s action manager filters it out because <code>externallyAvailable() </code>defaults to <code>FALSE</code></li>
<li>Drupal can no longer resolve <code>node_promote_action</code> during config import</li>
</ul>
<p>The filtering happens in:</p>
<ul>
<li> web/modules/contrib/eca/src/PluginManager/Action.php</li>
<li> specifically <code>Action::getDefinitions()</code> and <code>filterEcaDefinitions()</code></li>
</ul>
<p> The relevant logic is: if the plugin class implements <code>Drupal\eca\Plugin\Action\ActionInterface</code> return FALSE unless <code>externallyAvailable()</code> is TRUE</p>
<h4 id="summary-steps-reproduce">Steps to reproduce</h4>
<ol>
<li>Enable eca and eca_content.</li>
<li>Install a site that imports core node action config, or run a browser test/site install that boots with those modules enabled.</li>
<li>Let Drupal import system.action.node_promote_action.yml or the related node action config.</li>
<li>Observe the install/bootstrap failure.</li>
</ol>
<p>Expected result:<br>
Core node action config should import normally when eca_content is enabled. The following plugins should remain discoverable:</p>
<ul>
<li> node_promote_action</li>
<li> node_unpromote_action</li>
<li> node_make_sticky_action</li>
<li> node_make_unsticky_action</li>
</ul>
<p>Actual result<br>
Config import can fail with:</p>
<p><code>PluginNotFoundException: The "node_promote_action" plugin does not exist</code></p>
<h3 id="summary-proposed-resolution">Proposed resolution</h3>
<p>The smallest fix is likely to make <code>Drupal\eca_content\Plugin\Action\FieldUpdateActionBase::externallyAvailable()</code> return TRUE, because it is a compatibility base for core actions, not an ECA-only workflow action.</p>
<h3 id="summary-remaining-tasks">Remaining tasks</h3>
<ol>
<li>Discuss if the Proposed resolution is the right solution</li>
<li>Create MR</li>
</ol>
<h3 id="summary-ui-changes">User interface changes</h3>
<p>N/A</p>
<h3 id="summary-api-changes">API changes</h3>
<p>N/A</p>
<h3 id="summary-data-model-changes">Data model changes</h3>
<p>N/A</p>
> Related issue: [Issue #3588234](https://www.drupal.org/node/3588234)
issue