## Problem Three plugins are labeled "Persistent state", which every reader reasonably understands as Drupal's State API: | Plugin | Type | Label | Since | | --- | --- | --- | --- | | `eca_state_read` | action | `Persistent state: read` | 1.1.0 | | `eca_state_write` | action | `Persistent state: write` | 1.1.0 | | `eca_state` | condition | `Persistent state: compare` | 1.0.0 | They do not use it. `EcaState` extends `State` but rebinds the store in its constructor, `src/EcaState.php` line 42: ```php $this->keyValueStore = $key_value_factory->get('eca'); ``` So all three operate on a private `eca` key value collection. `drush state:set foo bar` is invisible to them, and a value written by `eca_state_write` is invisible to `drush state:get`. Demonstrated with a single model, with core state holding one value and the `eca` collection holding another: ``` ECA_STATE=partner CORE_STATE=WEB_FROM_CORE_STATE ``` ## Why the label matters more than it looks The failure is silent in the worst way. A model configured against `drush state:set` reads an empty token, and `action_message_action` with `replace_tokens: true` renders the blank without complaint, so the model appears to run correctly while testing nothing. There is no error, no warning and no log entry pointing at the store. Nothing in the plugin metadata corrects the impression either. The label says persistent state, the config schema says nothing about a collection, and the field descriptions do not mention one, so a reader has no way to discover the distinction short of reading `EcaState.php`. It cost a full debugging cycle to find while building an ECA Guide library model, and it will cost the same to anyone who follows the same reasonable path. There is also a near neighbor that makes the confusion easy to fall into. Since 2.0.0 the module ships `eca_keyvaluestore_read` and `eca_keyvaluestore_write`, labeled "Key value store: read" and "Key value store: write", which take an explicit `collection` and *can* reach Drupal core's `state`. So the module offers two families whose names suggest the opposite of what each one does: the plugins named after state cannot reach core state, and the plugins named after the key value store can. The naming is historical rather than deliberate. The state plugins arrived in 1.0.0 and 1.1.0, before the generic key value store plugins existed in 2.0.0. ## Proposed resolution Change the three labels so that they name the store they actually use. Something that carries the word "ECA" does the job, because the point to convey is that the store belongs to ECA rather than to Drupal: - `ECA state: read` - `ECA state: write` - `ECA state: compare` Alternatively, name the mechanism outright, which is less elegant but leaves no room for the assumption at all: - `ECA key value store: read` and so on, matching the existing "Key value store" family, given that the `eca` collection is exactly what these reach. The label is not a machine name, so existing models keep working and no update path is required. The generated documentation page paths derive from the plugin ID rather than the label, so the ECA Guide pages do not move either. Worth doing in the same pass, and arguably more valuable than the label on its own, is extending each plugin's description to state which store it uses and to point at `eca_keyvaluestore_read` / `eca_keyvaluestore_write` with `collection: state` for anyone who wants core state. The description is what the ECA Guide renders on the plugin page, so it reaches readers who never open the plugin selector. The Guide side is being corrected separately in its own issue, where the current text is not merely silent but wrong: it says these plugins read and write "the Drupal state". ## Remaining tasks - Decide between the two labeling options. - Extend the three plugin descriptions to name the store. ## User interface changes The three plugin labels change in the modeler's plugin selector and anywhere else plugin labels are rendered. No machine names change. ## API changes None. ## Data model changes None. Existing models continue to work unchanged. > Change record: [#3621191](https://www.drupal.org/node/3621191)