I'm seeing what feels like an oddity around UUIDs for pathauto pattern configurations, resulting in complexity around our config/code versioning workflow.

Repeatability

Every time a pattern is saved.

Steps to reproduce:

  1. Create a pathauto pattern
  2. Export configuration (drush config-export or via GUI)
  3. "Edit" the pattern and save, with or without changes
  4. Export configuration again

Expected result

UUID visible in the export steps remains consistent.

Actual result

The UUID is different, and is regenerated each time the pattern is saved.

Notes

This may be expected behaviour but it's causing us some workflow and config sync issues. (Although once we've stabilised our patterns it won't be an ongoing problem.)

We've been working around it in the meantime by generating UUIDs in production and manually replacing them in our local code before committing, but I'm worried this may have unintended consequences.

Comments

Jimaginary created an issue. See original summary.

Berdir’s picture

Version: 8.x-1.0 » 8.x-1.x-dev
Category: Support request » Bug report

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.

nedjo’s picture

Status: Active » Postponed

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

Berdir’s picture

Status: Postponed » Active

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.

nedjo’s picture

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