### Problem/Motivation `modules/content/eca_content.module` is the last remaining `.module` file in the whole ECA repository. It contains nothing but a `class_alias()` that claims core's class name for ECA's own base class: ```php if (!class_exists('Drupal\Core\Field\FieldUpdateActionBase', FALSE)) { class_alias('Drupal\eca_content\Plugin\Action\FieldUpdateActionBase', 'Drupal\Core\Field\FieldUpdateActionBase'); } ``` The intent (#3231933) is sound: core's `FieldUpdateActionBase::execute()` ends in `$entity->save()`, which must not happen inside an ECA context, least of all in a `content_entity:presave` model. The mechanism, however, is a race, and it has already cost two follow-up bugs. To be explicit about what this issue is **not** about: `.module` files are not deprecated. Change record [#3613767](https://www.drupal.org/node/3613767) (Drupal 12) consolidates procedural hooks *into* the main extension file, and `Extension::load()` is unchanged on `12.0-dev`. There is no external forcing function here. The reasons to remove the alias are its own: **1. It wins an autoload race by design.** `class_exists(..., FALSE)` suppresses autoloading, so the alias only takes effect when nothing has loaded core's real class yet. If something already has, the alias silently no-ops and ECA reverts to core's save-happy behavior with no warning at all. That guard exists because of #3266475 ("Cannot declare class Drupal\Core\Field\FieldUpdateActionBase"). **2. It has already produced a second bug.** The `externallyAvailable(): TRUE` override on ECA's base exists only to fix #3588862 ("ECA Content hides core node action plugins during config import") — a bug the alias itself introduced by turning four core plugins into subclasses of ECA's `ActionInterface`. **3. Its blast radius is wider than advertised.** With the alias in place, core's four node action plugins inherit ECA's `final __construct()` (nine arguments) and `create()`, so they are container-instantiated with `eca.token_services`, `eca.state` and `logger.channel.eca` **everywhere in Drupal** — the core action UI, Views Bulk Operations, everything — not only inside ECA. ### Affected plugins Exactly four classes import the aliased name, all in node: | Plugin ID | Class | | --------- | ----- | | `node_promote_action` | `Drupal\node\Plugin\Action\PromoteNode` | | `node_unpromote_action` | `Drupal\node\Plugin\Action\DemoteNode` | | `node_make_sticky_action` | `Drupal\node\Plugin\Action\StickyNode` | | `node_make_unsticky_action` | `Drupal\node\Plugin\Action\UnstickyNode` | ECA's own `SetFieldValue` extends the base by its real namespaced name and is unaffected. Core's `PublishAction` and `UnpublishAction` extend `EntityActionBase` and are out of scope. Contrib actions extending core's base are covered by the alias today, and the fix must preserve that. ### Proposed resolution Replace the alias with a `hook_action_info_alter()` implementation in `eca_content` that rewrites the definition's `class`. ECA already owns that seam: `Drupal\eca\Hook\PluginHooks` implements `hook_action_info_alter()` for the parent module and already mutates `$definition[$key]`. The remap runs during plugin discovery, after module load, so it is deterministic instead of racy. The remap is keyed on the **subclass relation**, not on a hardcoded plugin-ID list, so contrib actions extending core's base stay covered — both present and future ones. Note that a per-plugin approach (four thin node subclasses) was considered and **rejected**: `Drupal\eca\Plugin\Action\ActionBase::__construct()` is `final` with nine DI arguments, so a replacement class cannot extend both ECA's base and a foreign class. Hardcoded subclasses therefore cannot cover arbitrary contrib subclasses. A single generic class is used instead — which is also less code. 1. Add `Drupal\eca_content\Plugin\Action\CoreFieldUpdateAction`, a concrete subclass of `Drupal\eca_content\Plugin\Action\FieldUpdateActionBase` carrying **no** `#[Action]` attribute, so plugin discovery ignores it. It resolves its field map from the original plugin class, which the hook preserves in the definition under `eca_original_class`. 2. Because the original's `getFieldsToUpdate()` is `protected` and non-static, resolution goes through reflection. The instance is obtained with `newInstanceWithoutConstructor()` and `PluginBase`'s `configuration`, `pluginId` and `pluginDefinition` properties are assigned directly. This is agnostic to unknown constructor signatures and needs no container access. The result is memoized, since `access()` asks for the map in a loop. 3. Add a `#[Hook('action_info_alter')]` in `Drupal\eca_content\Hook\PluginHooks` that skips any class already implementing ECA's `ActionInterface` (which keeps `SetFieldValue` untouched and makes the remap idempotent) and otherwise remaps every `is_subclass_of(..., Drupal\Core\Field\FieldUpdateActionBase::class)` definition. 4. Delete `modules/content/eca_content.module`. Persisted configuration is unaffected. ECA's base short-circuits its entire configurable surface for anything that is not `SetFieldValue` (`defaultConfiguration()`, `buildConfigurationForm()` and `submitConfigurationForm()` all return early), so the four node plugins expose exactly one key today — `object` — and will continue to. **No model migration is needed.** Two runtime behaviors are preserved by the replacement, both currently supplied only by the aliased base: * **No premature `$entity->save()`.** `save()` fires only when `save_entity` is set or `!Processor::get()->isEcaContext()`. * **The NULL guards in `access()` and `execute()`.** `EcaAction` calls `access(NULL, NULL, TRUE)` when no entity resolves. Core's version raises an `\Error`, which escapes the `catch (\Exception)` in `EcaAction`, making that an uncaught fatal rather than a logged ECA warning. `externallyAvailable(): TRUE` on the base **stays**. Remapped plugins are ECA subclasses again, so `Drupal\eca\PluginManager\Action::filterEcaDefinitions()` still applies to them and the #3588862 fix remains load-bearing. Finally, resolution failures throw rather than degrading silently. A missing or unloadable `eca_original_class` raises a `\LogicException` naming the plugin ID, and anything thrown while reading the field map — including an `\Error` from an uninitialized property on an exotic subclass — is converted into a `\RuntimeException` so ECA can log it instead of dying. ### Remaining tasks * [x] Add `CoreFieldUpdateAction` and the `action_info_alter` remap. * [x] Delete `modules/content/eca_content.module`. * [x] Assert that all four node action IDs survive `Action::get()->getDefinitions()` and are present in the decorated inner manager, with `class` remapped and `eca_original_class` preserved. `tests/src/Kernel/ActionDecoratorTest.php` covered neither before, which is how #3588862 shipped. The same test also asserts that *only* those four definitions use the replacement class, which verifies empirically that discovery ignores an attribute-less class under `Plugin/Action/`. * [x] Add a kernel test for the NULL-object path (`access(NULL)`) covering the `\Error` vs `\Exception` gap. * [x] Confirm `tests/src/Kernel/Model/EntityBasicsTest.php` still passes: `eca.eca.eca_test_0004.yml` drives `node_make_sticky_action` and `node_promote_action` directly from `content_entity:presave`. > Change record: [#3621190](https://www.drupal.org/node/3621190)