UUID is regenerated every time a pattern is saved

Ah yes, that's the UUID of the conditions, not the UUID of the config entity.

That currently happens due to \Drupal\pathauto\Entity\PathautoPattern::addSelectionCondition() and how it is used in the UI. Would need to be refactored somehow to update the conditions instead. Conditions can be added or removed, so that might be a bit tricky to track.

But agreed that this is a bug.

Looks like this might be avoided by #3002529: Defer pathauto.pattern uuid config schema to config_entity. Postponing pending a resolution there.

That's not related, this isn't the top-level UUID, it's the UUID of the conditions The UI needs to be adjusted to not replace the conditions everytime or atleast re-use the existing UUID's.

@Berdir, ah, right, thx for catching that!

Added change to \Drupal\pathauto\Entity\PathautoPattern::addSelectionCondition() which persists the UUID if the configuration includes a uuid property saving the need to regenerate a unique UUID everytime.

This looks good at first glance, but it's a non-trivial amount of code to the form handling, would be great to make sure we have tests covering this. There is \Drupal\Tests\pathauto\FunctionalJavascript\PathautoUiTest::testPatternsWorkflow, where we add, edit and delete patterns, but we have little coverage for the conditions, specifically nothing about removing them.

So, would be good to extend that by removing the bundle condition and then also once save a pattern and ensure nothing on the config entity changes (load config entity, toArray(), save in UI without changes, then load again and compare)

Here's what the newly added tests cover:

• testSelectionCriteriaUuidPreservedOnSave: Creates a pattern with a bundle condition, records the UUID, then re-saves it by calling addSelectionCondition() with the existing UUID (as the edit form does). Asserts the UUID stays the same after reload.
• testSelectionCriteriaNewUuidGenerated: Verifies that adding conditions without a UUID correctly generates unique UUIDs for each condition. This ensures the fix didn't break the normal path for new conditions.

Code review of MR #78

The two commits fix the issue where selection condition UUIDs were regenerated every time a pattern was saved, causing unnecessary config diffs for teams managing configuration through version control.

Changes

PathautoPattern::addSelectionCondition() — When a uuid key is present in the configuration array and a condition with that UUID already exists, the method now updates the existing condition in place instead of generating a new UUID. New conditions (without a UUID) still get a fresh UUID as before.

PatternEditForm — The form previously removed all bundle and language conditions then re-added them on every save, which triggered new UUID generation. It now builds a mapping of existing plugin IDs to their UUIDs and passes the existing UUID to addSelectionCondition(). Conditions are only removed when the user actually unchecks them (via new elseif branches).

Kernel tests — Two tests verify the fix:

• testSelectionCriteriaUuidPreservedOnSave: confirms UUIDs remain stable after re-saving a pattern with existing conditions.
• testSelectionCriteriaNewUuidGenerated: confirms new conditions still receive unique UUIDs.

The fix looks correct. The root cause (remove-then-readd pattern in the form) is replaced with an update-in-place approach, and the entity class properly supports UUID preservation.

Correct me if I am wrong, but #3577286: Drupal core 11.3.4 removed uuid from condition plugin schema which causes schema errors in pathauto pattern configuration (triggered by #3525391: Conditions plugin validation schema is wrong) makes this issue completely obsolete.

Don't we need to remove all uuid from existing configuration first?

Maybe we should wait until the related issue is fixed before closing this one, or mark it as a duplicate.

I feel like we could still have a problem with the condition configuration key names:

Without this issue's fix, the config keys including the generated condition UUID would still change on each save.

But may be, it's not really a problem?

The conditions are still keyed by a UUID and that should be stable, this causes unessesary config changes

Seems much easier now, nice. I don't think the kernel tests are doing much at this point, all the logic is in the form, so we should test that? We can possibly extend some existing edit tests and assert that the UUID's don't change ther?

Updated the test to simulate a form edit, ensuring it fails if the fix is not applied.

Also added some assertions to the PathautoUiTest functional Javascript test.

Looks good to me. Do we have existing coverage of removing language/bundle condition through the UI or should we add that too?

Then I think this is ready.

Added some feedback on the test, I think fine to merge then afterwards.