task: #3532791 Let the element own the store and the route in its process callback (!61) · Merge requests · project / autocomplete_deluxe

Does what #3532791 asked for.

What it does

AutocompleteDeluxeElement::autocompletePath() now puts the selection settings in the key value store and builds the path to the route, and the process callback of the element calls it. The widget no longer does any of it.

Two things follow from that:

Nothing placing the element has to know how the key is hashed or which route to name. The README examples lost about fifteen lines each.
An alter is taken into account, because a process callback runs after hook_field_widget_single_element_form_alter().

Setting #autocomplete_deluxe_path yourself still works and still wins, so code written against the older element is unaffected.

The alter really does take effect now

A throwaway module set #selection_settings['match_operator'] to STARTS_WITH in hook_field_widget_single_element_form_alter(), on Drupal 11.4.5:

	key	typing "storm"
Without the alter	`HkiKGu10tTrjk6X1Uqf-...`	Hailstorm, Thunderstorm
With the alter	`374LJjtSA9To15weKYci...`	nothing, correctly

The key changes, so the altered settings are what got hashed and stored. Before this change the widget had already hashed and stored them, and the alter did nothing at all.

One thing worth checking in review

The element property #selection_settings carries the entity being edited, added for #3268207, while the hash must not carry it or the store would grow a key per entity. autocompletePath() takes the entity out before hashing and storing, and the entity still reaches the controller through the query parameters.

Checked on Drupal 11.4.5: the key is the same on the add form and on the edit form of two different nodes, and the store stayed at two keys throughout.

Back compatibility

$this->keyValue stays on the widget, unused, so that code building the widget with the same argument list keeps working.

Test coverage

tests/src/Kernel/AutocompletePathTest.php, four cases:

The path names the route and the settings land in the store under the key it carries.
The same settings give the same key, so the store does not grow.
The entity being edited changes neither the key nor what is stored, and one field keeps one key.
Altered settings give a different key, which is what this issue was about.

The third one is the one that matters most. Putting the entity back into the hash makes it fail with "Failed asserting that two strings are identical", so the store cannot quietly start growing a key per entity again.

Checkpoints

AI-Generated: Yes (moving the store and route into the process callback, plus its kernel test; reviewed by rajab natshah.)

Edited Sep 01, 2026 by Rajab Natshah

task: #3532791 Let the element own the store and the route in its process callback