## Summary Two defects in the Metatag automator, both independent of the decoding regression fixed in #3586713 and both invisible until that one is fixed, because until then nothing was stored at all. 1. **Every tag is offered to the model, not the configured ones.** `extraAdvancedFormFields()` renders a textarea for every tag Metatag knows about, so the saved configuration carries a key for all of them. `generate()` builds its "available tags" list from those keys rather than from the ones holding a subprompt. The form is explicit that an empty one means *"Keep empty to not generate anything"*, but the prompt tells the model all of them are fair game. 2. **Only one generated tag is stored.** The prompt asks for a single record holding every configured tag, but models routinely answer with one record per tag. `storeValues()` reads a single entry out of the generated values, so the rest are dropped. ## Steps to reproduce 1. Create a content type with a `metatag` field and enable the AI Automator on it with `LLM: Meta Tags`. 2. Set **Automator Base Field** to Title, and give the node a title. 3. Under the tag groups, fill in a subprompt for **exactly one** tag (e.g. Abstract). Leave every other tag empty. 4. Save, then run the automator on a node. ## Expected result Only the Abstract is generated and stored. Every other tag is left alone, as the field description promises. ## Actual result The model is told 110 tags are available: ``` The list of available tags is: title, description, abstract, keywords, geo_region, geo_position, geo_placename, icbm, robots, canonical_url, shortlink, next, prev, original_source, generator, image_src, author, google, rating, refresh, ... Do not generate values for any other tags. ``` and answers with 13 of them: ``` [0] {"title":"10 Best Drupal Modules for 2024 | Top Picks"} [1] {"description":"Explore the 10 best Drupal modules for 2024..."} [2] {"abstract":"Tired of boring Drupal sites?..."} [3] {"keywords":"Drupal modules, 2024, best modules, ..."} [4] {"og_title":"10 Best Drupal Modules for 2024"} ... [16] {"canonical_url":"https://example.com/10-best-drupal-modules-2024"} ``` Of those, `storeValues()` keeps one and discards the other twelve. Which one survives depends on the order the model happened to answer in. So the same run both over-generates (tags nobody asked for, including ones a site builder may maintain by hand) and under-stores (12 of 13 dropped). Counted on the reproducing install: ``` tags with a config key (what the prompt called 'available'): 110 tags with an actual subprompt (what was configured): 1 ``` ## Suggested fix - `generate()`: build `$available_tags` from the tags carrying a subprompt, so unwanted tags never reach the model. This also stops sending ~110 irrelevant tag names in every request. - `storeValues()`: merge every returned record into one tag set rather than reading a single entry, and intersect the result with the configured tags so a generated `title` cannot overwrite a hand-maintained one. A tag the model repeats (`article_tag`, for example) keeps its first value, since the field stores one value per tag. Verified after the change, same configuration and model: ``` tags advertised to the model now: 1 -> abstract model returned 1 value(s): [0] {"abstract":"Tired of boring Drupal sites? Meet the 10 modules that'll..."} stored on the field: {"abstract":"Tired of boring Drupal sites? ..."} ``` ## Not a release blocker for 1.5.x Both defects are old bugs, not regressions. Verified by reading the code out of the 1.4.8 tag, the last 1.4 release: ``` # 1.4.8, PluginBaseClasses/Metatag.php 139: $available_tags[] = substr($key, strlen('llm_tag_value_')); # unconditional $entity->set($fieldDefinition->getName(), Json::encode($values[0])); ``` Both lines are present verbatim. Traced to their introducing commits: | Defect | Commit | Date | First release | |---|---|---|---| | Over-broad tag list | `a641fd91` | 2026-02-23 | 1.3.0 | | Single generated value stored | `d1703746` | 2025-01-25 | 1.0.4 | The single-entry read has shipped for roughly twenty months. Neither was introduced in 1.5.x, so neither should carry the release blocker label. This is the opposite of the parent issue. #3586713's decoding regression came from `1f45406f` (2026-08-05, issue #3586468) and is contained only in `1.5.0-rc1`, `rc2` and `rc3`, never in a stable release, so that one is correctly a release blocker. The two are connected: these defects were invisible on 1.4.x precisely *because* metatag worked there. Records survived decoding, `$values[0]` was the whole tag set, and the model's over-generation landed in a blob the widget then filtered down. The regression is what exposed them. ## Notes - Restricting generation and storage to configured tags is a behaviour change. Anyone relying on the model volunteering extra tags will now get only what they asked for. That matches the field description, but it is worth a maintainer's second opinion. - Blocked by #3586713: without that fix nothing is stored at all, so neither defect is observable. - Do not carry the release blocker label across from #3586713. See the section above.