Contrib.social

Parent Issue: Create Field Widget Actions plugins for Automators.

Open on Drupal.org →
Created on 7 July 2025, about 1 month ago

Problem/Motivation

NOTE - IMPORTANT: This is a parent issue, if you want to start working on a specific widget and automator combination, please create a child issue using the template below.

The Field Widget Action module is merged into 1.2.x, together with currently three widgets in the AI Automators:

In this process also the following have been made to make development/testing faster going forward:

  • A base class for all Automators Field Widget Plugins.
  • Any specific UI rules for a button, moves to a trait, see the trait for Image Alt Text where we have to make sure its just used when an image exists. These traits can be used by any consumer of the Field Widget Actions, and should be places in that module, rather than the Automators.
  • Functional Javascript tests, with a whole setup of a widget and a browser actually clicking the widget action. Make sure to use the AI base class and the takeScreenshot, and you can get screenshots of the process while doing it in a test.

Proposed resolution

Now we need the communities help to start pushing out a lot of Field Widget Actions for all the different field form displays that the field types that the Automators supports.

This means a combination of one or many Automator Types, that can be found under src/Plugin/AiAutomatorType and one or many form display types that will work the same.

So for instance you can decide to do the "llm_link" automator type, that maps to "link" field and the "link_default" form display type, but not the "linkit".

To be able to start on such an issue, you should:

  1. First check the issue queue so it has not already be created.
  2. Then create an issue using the Feature Issue Template below.
  3. Attach that issue as a child to the issue you are looking at here.
  4. This means that this issue your are looking at here, should not be worked on and should only be deemed finished when all the base Automators are covered.
  5. All issues gets 1 credit, even if a integer field is 100 times simpler then the Custom Field type.
  6. If anything is missing in the base class, please add it there in your MR.
  7. If a trait is missing for an UI, please add it to the Field Widget Action module in your MR.

Feature Issue Template

<h3 id="summary-problem-motivation">Problem/Motivation</h3>
The Field Widget Action module is merged into 1.2.x, however we need to start adding Automators plugins to it. The parent issue [#] is a parent issue for all the implementations of the Automators plugins. Read more in the parent issue.

This is the implementation of the Field Widget Action(s) [field_widget_actions] for the AI Automator Type(s) [ai_automator_types].

<h3 id="summary-proposed-resolution">Proposed resolution</h3>

<ul>
  <li>In the AI Automators module, create a new Field Widget Action plugin under src/Plugin/FieldWidgetAction.</li>
  <li>Call it [fieldWidgetActionsAiAutomatorType].php</li>
  <li>Use the FieldWidgetAction attribute and connect it to the correct widget_types and field_types</li>
  <li>At minimum, set up the first part of the aiAutomatorsAjax, where it picks the correct components, and if it should clearEntity and the formElementProperty. clearEntity, means that it removes the enities, to recreate them for the Automators, this should not be set if its a subfield.</li>
  <li>Manually test that its working and record a video of it working and upload to the feature (could be done by a reviewer).</li>
  <li>(optional, can be removed) Write at least a kernel test of the ajax function</li>
  <li>(optional, can be removed) Even better Function Javascript tests, but that is optional.</li>
</ul>
✨ Feature request
Status

Active

Version

1.2

Component

AI Automators

Created by

🇩🇪Germany marcus_johansson

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @marcus_johansson
  • Comment about 1 month ago →
    🇩🇪Germany marcus_johansson
  • Comment about 1 month ago →
    🇩🇪Germany marcus_johansson
  • Comment about 1 month ago →
    🇮🇳India anjaliprasannan
  • Comment about 1 month ago →
    🇮🇳India anjaliprasannan
  • Comment about 1 month ago →
    🇩🇪Germany marcus_johansson

    Setting to postponed for now - we might find a way to have just one plugin. Will re-open if I fail.

  • Comment about 1 month ago →
    🇨🇦Canada bisonbleu

    Recently spent quite a bit of time figuring and working on a few of those Automator plugins (boolean, email, list_float, list_integer, list_string). And in this process, the code duplication has become obvious.

    Now I'm thinking «there’s got to be a better way…?» Maybe a deriver?

    Here’s what Claude.ai had to say. And from what I gathered working on these plugins, it kind of makes sense - especially if you accept to trade code duplication for a bit more complexity.

    Tier 1: Base Deriver for Simple Fields

    Create a deriver that generates plugins for field types that follow Pattern A:

    • string, text, email, integer, float, list_integer, list_float, boolean
    • Configuration-driven: widget types, field types, form element property
    • Handles 80% of use cases with zero code duplication

    Tier 2: Manual Plugins for Complex Fields

    Keep hand-coded plugins for Pattern B/C:

    • link, image, entity_reference, specialized widgets
    • Cases requiring custom saveFormValues(), traits, or complex logic

    Tier 3: Override Mechanism

    Allow manual plugins to override deriver-generated ones when needed.

    But is the cognitive complexity of a deriver system worth eliminating the maintenance complexity of duplicated code? I’m leaning towards «not worth it». Code duplication is easier to work with, I can deal with that extra entropy.

    Another option (?):

    • Move aiAutomatorsAjax() to Base Class;
    • Create helper methods in base Class e.g. getFieldValue(), setStandardFormValue() to simplify plugin structure;

    This might make it possible to reduce code duplication / plugin size by more than 50% ?

    It's possible that my vision might be too localized - i.e. the depth of filed is limited and I'm not getting the greater picture of the universe…

  • Comment 29 days ago →
    🇩🇪Germany marcus_johansson

    Activating this again - from what I have seen there are similar widgets that can be merged, but that is easier to see while/after they are written anyway.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024