Conflict with Canvas and Rename filename Automator

This issue is for onboarding new contributors

I am going to take a quick stab at this... Trying to reproduce...

`AutomatorBaseAction::saveFormValues()` calls `$item->get('value')` on image field items, but image fields don't have a `value` property (they have `target_id`, `alt`, `title`, `width`, `height`). This causes `InvalidArgumentException: Property value is unknown.`
Additionally this is not a canvas specific issue, as the core ImageItem itself lacks the `value` and canvas ImageItemoverride inherits ImageItem

.

My bad its been some time I did a proper d.o contrib, I hope the steps i followed above is fine.
I mistakenly bumped up the version earier but I just moved it back to the original version mentioned in the issue.

And yeah here is the issue being reproduced:

and here is the post fix ss:

Root Cause: AutomatorBaseAction::saveFormValues() calls $item->get('value') on image field items, but image fields don't have a value property (they have target_id, alt, title, width, height). This causes InvalidArgumentException: Property value is unknown.

Not Canvas-specific. Core ImageItem also lacks value. Canvas's ImageItemOverride inherits from ImageItem and doesn't change the property set. Compare with ImageAltText which works fine because it uses $formElementProperty = 'alt' — a valid image property.

Fix: Add a property existence check at the top of AutomatorBaseAction::saveFormValues():

$field_items = $entity->get($form_key);
$first_item = $field_items->first();
if ($first_item) {
  $property_definitions = $first_item->getFieldDefinition()
    ->getFieldStorageDefinition()
    ->getPropertyDefinitions();
  if (!isset($property_definitions[$this->formElementProperty])) {
    return $form[$form_key];
  }
}

The early return is correct here because LlmRewriteImageFilename::storeValues() already renames and saves the File entity directly — there's no field item property to read back.

Tested: Reproduced the exact error with Canvas + AI Automators on a Media Image form. After the fix, clicking "Automator Image Filename Rewrite" no longer crashes. All text-based field types (string, text, list_string, boolean, email, etc.) are unaffected — they have value in their property definitions and continue through the normal code path.

MR: https://git.drupalcode.org/project/ai/-/merge_requests/1288

Steps to reproduce

1. Enable ai_automators and canvas modules (drush en ai_automators canvas)
2. Create an AI Automator config for Media → Image → field_media_image using the "LLM Rewrite Image Filename" rule
3. Go to Admin → Structure → Media types → Image → Manage form display
4. On the field_media_image widget, enable the "Image Filename" field widget action and select your automator
5. Go to Content → Media → Add media → Image, upload any image
6. Click the "Automator Image Filename Rewrite" button
7. Before fix: InvalidArgumentException: Property value is unknown. in AutomatorBaseAction::saveFormValues() (usually a ajax console error)
8. After fix: Automator runs, renames the file, no error

Steps to verify the fix doesn't break other fields

1. Create an AI Automator for a text field (e.g. title or a plain text field)
2. Enable the automator widget action on that field's form display
3. Trigger the automator — should still work as before (text-based fields have value and pass the property check)

AI usage

• [ ] AI Assisted Issue
  This issue was generated with AI assistance, but was reviewed and refined by the creator.
• [ ] AI Assisted Code
  This code was mainly generated by a human, with AI auto-completing or parts AI generated, but under full human supervision.
• [X] AI Generated Code
  This code was mainly generated by an AI with human guidance, and reviewed, tested, and refined by a human.
• [ ] Vibe Coded
  This code was generated by an AI and has only been functionally tested.

Hi @ajv009, I've tested this issue multiple times, but it doesn't seem to work for me. Maybe I'm doing something wrong. I've attached a video showing my test. The filename doesn't change, and no error message is displayed.

Please let me know if I need to enable or add any additional settings to make it work.

Hey @cadence96, thanks for testing this out! I went back and reproduced the issue again from scratch on a clean Drupal 11.3.5 + AI 1.2.x-dev (9831ffd) + Canvas 1.3.1 setup using ddev, and I can confirm the original InvalidArgumentException is definitely still there without the fix:

InvalidArgumentException: Property value is unknown.
in Drupal\Core\TypedData\TypedDataManager->getPropertyInstance() (line 204)

About your test where the filename doesn't change and no error is displayed — I think what's happening is the fix in MR !1288 is actually working (no more crash!), but you might not have an LLM provider configured yet. Without one, the automator runs but has nothing to generate a new filename with, so it just silently does nothing. Could you check /admin/config/ai and make sure you have a provider set up for the "chat" type? The watchdog log might show something like "No provider set for the LLM type chat".

Also, one thing that tripped me up during setup — the way the automator config entity is created matters a lot. If you used the dedicated add form at /admin/config/ai/ai-automators/ai-automator/add, that form is actually broken on 1.2.x-dev (crashes with Typed property AiAutomator::$entity_type must not be accessed before initialization — related to #3558728: Add AI Automator field form breaks if fields not available in any bundle which covers the same calculateDependencies() crash for $field_name). The proper way to set it up is through the field config form: Structure → Media types → Image → Manage fields → field_media_image → Edit, and enable the automator from there. That path properly populates the plugin_config array which the runtime code depends on.

If you created the automator a different way (drush, config import, etc.), the plugin_config might be empty, which causes a different error — PluginNotFoundException: The "" plugin does not exist — that can also look like "nothing happens" from the UI side. This was also reported in #3577812: AiAutomatorEntityModifier::entityHasConfig() missing weight and worker_type causes crash on node save (closed as cannot reproduce, but it does happen with programmatically created automators).

Here's what worked for me to reproduce end-to-end:

1. ddev composer create drupal/recommended-project:^11
2. ddev composer require drush/drush drupal/ai:1.2.x-dev drupal/canvas drupal/token
3. ddev drush site:install -y && ddev drush en media media_library ai_automators canvas field_widget_actions -y
4. Set up the automator through the field config form (Manage fields → Edit field_media_image)
5. Enable the "Automator Image Filename Rewrite" widget action on Manage form display
6. Upload an image at /media/add/image and click the button

Could you give it another try with those steps and let me know if you see the same results? If the fix is applied and you have a provider configured, it should work — the filename should change and no error should appear.

The root cause is the same as I described in comment #11 — saveFormValues() tries to read 'value' from image field items, but image fields don't have that property. The early return in the fix is safe because LlmRewriteImageFilename::storeValues() already handles the rename directly on the File entity.

Transparency note: This comment was synthesized — the issue research, environment setup, and reproduction were done using Claude Code (autonomous AI tooling). I personally supervised the entire process as part of an ongoing experiment on the reliability of using autonomous kanbans for contribution workflows. No intent to demean anyone's effort here — everyone's work on this issue has been valuable. If I'm not doing something right process-wise, please flag it and I'll course-correct.

Maybe instead of doing the potentially dangerous change in the Automator Base class, it makes more sense to fix it in ImageFilename class instead?

Either by setting the correct field property, changing this:

  /**
   * {@inheritdoc}
   */
  public string $formElementProperty = 'value';

to

  /**
   * {@inheritdoc}
   */
  public string $formElementProperty = 'target_id';

or alternatively override the saveFormValues method in ImageFilename class like:

  protected function saveFormValues(array &$form, string $form_key, $entity, ?int $key = NULL): array {
    return $form[$form_key];
  }

Do you agree?

I think that fixing base class is also a good idea, but it might potentially bring some problems with other plugins (I am not saying that it will, but might be somehow).

Hey @a.dmitriiev, fair, but I went and audited all 12 plugins extending AutomatorBaseAction to see if the base class change could cause trouble. Here's what I found:

Every existing plugin sets a $formElementProperty that actually exists on its target field type ('value' for text/number/boolean/list/email, 'alt' for ImageAltText, 'target_id' for entity_reference, 'uri' for link, 'summary' for text_with_summary). The only plugin where the property doesn't match is ImageFilename, which sets 'value' on an image field. So the defensive check in the base class would only trigger for ImageFilename today, and wouldn't change behavior for anything else.

On your two suggestions:

• Setting $formElementProperty = 'target_id' would pass the property existence check, but then saveFormValues() would try to write to $form[...]['target_id']['#value'], which doesn't exist as a form element in image widgets. The image widget doesn't expose target_id as an editable input, so that could cause a different error.
• Overriding saveFormValues() to just return $form[$form_key] works and makes it explicit that this plugin doesn't need to write anything back. I mean, that's good, I think.

I think doing both could be the cleanest path: override saveFormValues() in ImageFilename so the intent is clear, and keep the base class check as a safety net for future plugins that might hit the same mismatch. But I'm also fine with just the local fix if you feel strongly about keeping the base class untouched. I might not be the right voice here as I am just reviewing what was raised or asked in the issue...

Unrelated thing I noticed while auditing: a few plugins use static::FORM_ELEMENT_PROPERTY (the constant, always 'value') instead of $this->formElementProperty (the instance property) in their aiAutomatorsAjax() methods. For example, SummaryTextareaWithSummary sets $formElementProperty = 'summary' but its AJAX handler uses the constant 'value' on line 37. Same thing in ClassificationOptionsSelect ('target_id' vs constant 'value', line 32). Compare with ImageAltText and ImageFilename which correctly use $this->formElementProperty. Not causing a crash right now since $form_key is read from index 0 of $array_parents, but it does build incorrect form paths. Probably worth a separate issue if it's not already tracked.

Transparency note: The plugin audit was done with Claude Code. I verified the findings by reading some plugin files. If anything looks off, happy to be corrected.

There will be a change in the Base class here #3577050: Generalize behaviour of FWA with Automators soon, that is why I would like to keep it untouched, maybe include the fix with additional checks in that issue instead.

Hmm, so the issue you mentioned basically fixes this on 1.3.x ...
In that case, yeah, this might be TOO big... might as well bring the change to local imageFilename temporarily, I suppose...
makes sense, I guess...

on it...

Tested on:

- Drupal 11.3.5
- AI 1.2.x-dev (branch 3561693-Conflict-Canvas-and-Rename-filename-Automator, commit df1439c9)
- Canvas 1.3.2
- PHP 8.4

Without the fix, clicking the "Automator Image Filename Rewrite" button throws InvalidArgumentException: Property value is unknown in AutomatorBaseAction::saveFormValues() as described.

Then with the fix applied, the button no longer crashes. The override of saveFormValues() in ImageFilename returning early is the correct approach since LlmRewriteImageFilename::storeValues() already handles the rename directly on the File entity.

Thank you! Merged and cherry picked to all active branches.

Let's continue with the fix to base class in #3577050: Generalize behaviour of FWA with Automators