## Problem `direct_fill` has no reachable configuration schema for any ECA-provided field widget action. Saving an entity form display that carries it raises `SchemaIncompleteException` on any development site. The observed symptom is a recipe or config import that reports success but leaves the third-party settings unsaved, so the buttons never appear. Applying a second time appears to fix it, which makes this look like a caching problem. It is not. ## Cause `config/schema/eca_field_widget_actions.schema.yml` declares: ```yaml field_widget_action.plugin.eca_field_widget*: type: field_widget_action_plugin_base mapping: direct_fill: type: boolean label: 'Fill the field directly' ``` The key uses a **partial-segment wildcard**, `eca_field_widget*`. Core's `TypedConfigManager::getFallbackName()` only ever replaces a **whole** dot- or colon-separated segment: ```php $replaced = preg_replace('/([^\.:]+)([\.:\*]*)$/', '*\2', $name); ``` It cannot produce a name like `eca_field_widget*`. For a derived plugin ID such as `eca_field_widget:eca_lib_0041.Event_suggest_title`, the fallback chain is: ``` field_widget_action.plugin.eca_field_widget:eca_lib_0041.Event_suggest_title -> field_widget_action.plugin.eca_field_widget:eca_lib_0041.* -> field_widget_action.plugin.eca_field_widget:*.* -> field_widget_action.plugin.*:*.* -> field_widget_action.plugin.* <- matched ``` Resolution lands on the generic key provided by `field_widget_actions`, whose `field_widget_action_plugin_base` has no `direct_fill`. Every other key — `plugin_id`, `enabled`, `button_label`, `weight` — validates against that base. `direct_fill` alone is unschema'd. The declared key is therefore dead: it can never be reached for any plugin ID. ## Why it is more than a warning `ConfigSchemaChecker::onConfigSave()` is documented `@throws \Drupal\Core\Config\Schema\SchemaIncompleteException`. It throws rather than logs, and the throw lands after the write in `Config::save()`: ```php $this->storage->write($this->name, $this->data); // data already written ... $this->eventDispatcher->dispatch(new ConfigCrudEvent($this), $event_name); // throws here ``` So the raw data is written, but `postSave()`, entity update hooks, static cache resets and the rest of the calling operation are abandoned. A recipe reports `[OK]` while having half applied. `ConfigSchemaChecker` is a development-only subscriber, so on a production site the same configuration saves with no schema validation at all and the problem is invisible. ## Steps to reproduce 1. Install `field_widget_actions` and `eca_field_widget_actions` on a development site with `twig.config.debug`-style development settings, so `ConfigSchemaChecker` is registered. 2. Create an ECA model with an event, giving a derived plugin ID such as `eca_field_widget:<model_id>.<event_id>`. 3. Attach that plugin to a field widget in Manage form display and enable "Fill the field directly". 4. Save. Expected: the setting persists. Actual: `Schema errors for core.entity_form_display.node.<bundle>.default ... third_party_settings.field_widget_actions.<uuid>.direct_fill missing schema`. ## Suggested resolution Declare `direct_fill` under a key the fallback resolution actually reaches. The simplest is to extend the generic key rather than introduce a module-specific one, since `field_widget_action.plugin.*` is where every derived ID resolves. Alternatively, if the setting should stay specific to this module's plugins, the key has to match on whole segments — for example `field_widget_action.plugin.eca_field_widget:*.*` — though note the chain above collapses to `field_widget_action.plugin.*:*.*` before reaching a three-segment form, so this needs verifying against the real resolution order. Either way the current key can be removed, because nothing can match it. ## Impact Any ECA-provided field widget action that enables direct fill, on any development site. Found while building a sample recipe for the ECA Guide; the sample has had to drop `direct_fill` to apply cleanly. AI-Generated: Yes (Used opencode to diagnose the schema resolution chain and verify it against Drupal core's `TypedConfigManager`, `ConfigSchemaChecker` and `Config::save()`.)