Field widget actions with ECA¶
Version v1
You can apply this model as a recipe (Drupal 10.3 or later) to your own Drupal site:
1 2 3 4 5 6 7 8 9 10 11 | |
Purpose¶
The contrib module Field Widget Actions attaches an action button to a field widget on an entity form. The bridge module ECA Field Widget Actions turns every ECA model that uses the "ECA Field Widget" event into one of those buttons, so the behavior behind a button is a model instead of custom code.
This model contributes two buttons, one per event. Both are deterministic and use no AI and no external service, so the example can be installed and explored right away.
How it works¶
The "Suggest a title" button returns three candidate values. Three "List: add item" actions build a list token named title_suggestions, and "Set field widget value" hands that token back to the widget. Because the token holds a list rather than a string, Field Widget Actions opens its suggestions dialog and the author picks one.
The "Insert byline" button returns a single computed string. Nothing builds a list here, so "Set field widget value" receives a plain string and that value goes into the field directly.
Both buttons read the entity that is currently being edited through the [entity] token, so the values they return follow whatever has already been typed into the form.
Where the behavior is configured¶
A field widget action only exists once it is attached to a widget in a form display, and the choice between offering suggestions and writing the value straight into the field is made there as well, not in the model. This recipe attaches both buttons to the Article form display: "Suggest a title" on the Title widget using the suggestions dialog, and "Insert byline" on the Body widget with "Fill the field directly" enabled.
To attach a button to another field, or to change that choice, go to "Administration / Structure / Content types / Article / Manage form display" and open the field widget action settings of a field.
Direct filling applies to a single scalar value only. Compound fields such as Link or Address and multi-value fields fall back to the suggestions dialog automatically, so the button stays usable either way.
Filling several fields at once¶
A field widget action cannot fill more than the one field its button belongs to. The Ajax response addresses a single form element, the one the clicked button sits inside, and the entity exposed as [entity] is a throwaway object built from the current form state, so changing other fields on it has no effect on the form. To populate several fields from one interaction, use a form event together with the "Form field: set value" action, or calculate the values when the entity is saved.
Requires ECA Field Widget Actions 1.0.0-beta2 or later¶
The "Fill the field directly" setting is stored as a direct_fill key in the widget's third-party settings, and up to and including 1.0.0-beta1 that key had no configuration schema Drupal could find. Its schema was declared under the name field_widget_action.plugin.eca_field_widget*, but a button provided by an ECA model has a derived plugin ID such as eca_field_widget:eca_lib_0041.Event_suggest_title, and Drupal resolves an unknown schema name by replacing whole dot-separated and colon-separated segments with a wildcard, one segment at a time. It never looks for a name that ends in a partial segment, so that declaration was unreachable. 1.0.0-beta2 moves it to field_widget_action.plugin.eca_field_widget:*.*, which Drupal does look for.
Composer cannot express that requirement here, because the recipe's composer.json is regenerated from the model on every export and always asks for any version. So the version has to be checked by hand, and it matters, because applying this recipe against 1.0.0-beta1 fails in two different ways depending on the site:
On a site with configuration schema checking enabled, which is usual for a development site, saving the form display raises an exception for the key that has no schema. Drupal writes the data first and dispatches the event afterwards, so the save is left half finished and the rest of the recipe is abandoned. The apply still reports success, and the buttons do not appear.
On a production site nothing checks the schema, so the recipe applies and the buttons work, but the configuration carries a key that no schema describes. Exporting and validating that configuration elsewhere will complain about it.
If composer require drupal-eca-recipe/eca_lib_0041 resolves ECA Field Widget Actions to 1.0.0-beta1, update that module before applying the recipe.
Requirements¶
This recipe installs the field_widget_actions, eca, eca_base, eca_field_widget_actions and modeler_api modules. eca_field_widget_actions has to be at 1.0.0-beta2 or later, for the reason described above.
It also applies core's article_content_type recipe, which provides the Article content type together with its body field. From Drupal 11.4 the Standard profile no longer creates that content type, so without this step the sample would install two buttons with nothing to attach them to.
Applying a recipe from within another one is not a pure no-op on an existing site. Configuration that is already present is never overwritten, but the included recipe also runs its own config actions, and those reset the components of the Article form and view displays to core's defaults. On a site whose Article displays have been customized, apply this recipe to a copy first.
Why the recipe ships a form display¶
A field widget action lives in the third-party settings of an entity form display, so the button only exists once that config entity does. On a fresh site it does not. Drupal creates entity form displays lazily: EntityDisplayRepository::getFormDisplay() builds an unsaved object on the fly when no configuration entry is found, and core notes that entries "are only created when an entity form display is explicitly configured and saved". The node form therefore renders perfectly well with no display configuration at all, which is why the absence is easy to miss.
The consequence is specific to this kind of button. A model that builds form elements at runtime is unaffected, because it never reads the display. A field widget action is read from the saved configuration, so with no configuration there is nothing to read and no button appears.
To close that gap the recipe ships core.entity_form_display.node.article.default in its own configuration directory. Recipes only create configuration that is absent from the site, so this lands on a fresh site and is ignored everywhere else: an existing Article form display, with whatever widgets and settings it already has, is left untouched. The buttons are then attached to it with a config action that merges into the components rather than replacing them.
Because the display is now guaranteed, that config action is not marked optional. If the display were still missing, applying the recipe would fail loudly rather than finish quietly with two buttons attached to nothing.
Dependencies¶
- module
- eca_base
- eca_field_widget_actions
- modeler_api