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&rsquo;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&rsquo;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