"The alias is already in use in this language" should not be thrown when "automatic URL alias" is enabled

That doesn't make sense to me.

Either you use a generated path, then no validation should be done because the displayed path is purely informal and has no meaning. Or you don't, but then it's not something that is related to pathauto? Are you sure that you are not using and core patches related to alias language handling/fallback?

alias lookup in core is language specific, I've never seen that validation error. Again, are you sure you're not using any patches to store aliases as langauge neutral or doing language fallback? are you using the language_hierarchy module for example?

Was this issue fixed?

I am facing the same error on a site where translation has never been enabled. There is a default user alias pattern 'users/[user:name]'. Attempts to edit a node intermittently trigger the error.

Uninstalled pathauto and I am still getting the error.

The issue seems to arise where there is more than one copy of an alias. cf https://agaric.gitlab.io/raw-notes/notes/2023-09-19-unable-to-create-new...

In my case there were duplicate aliases for some users, and a user with two identical alias records was intermittently locked out of editing. The duplicate aliases were probably generated by pathauto, but I am not sure I have enough detail to open a useful ticket.

EDIT my problem is not pathauto. LastPass browser extension has started auto-filling the alias field on the node edit form for some users. I am going to look at altering the form to prevent this happening. Password managers are not deterministic in deciding which fields to fill, so altering the form is not a realistic solution to prevent incorrect form fills. LastPass extension also creates problems on user edit forms, but auto-filling the alias field is new.

I am guessing my duplicate user aliases were generated during a D7-D8 migration.

I have been able to reproduce the problem locally when translating a content as described in IS.

Looks like an even better solution is to simply disable field validation when pathauto is active.

Updated MR accordingly.

False "alias already in use" on translation

The Problem

When two nodes in different languages share the same URL alias (which Drupal allows — e.g. /content/test-node for English and /content/test-node for French), adding a translation of one of them triggers a false validation error: "The alias is already in use in this language."

Root cause: The translation form inherits the source node's alias value.
When the parent PathWidget::validateFormElement() runs, it creates a temporary path_alias entity with the inherited alias and the target langcode (fr). The UniquePathAliasConstraint validator then finds the other French node's alias as a conflict (same alias + same langcode + different system path).

This validation is pointless when pathauto's "Generate automatic URL alias" checkbox is checked, because pathauto will regenerate and uniquify the alias during entity save anyway.

The Fix (PathautoWidget.php)

PathautoWidget::validateFormElement() now skips the parent validation entirely when the pathauto checkbox is enabled (!empty($element['pathauto']['#value'])). The inherited alias value is irrelevant since pathauto will replace it on save.

The Test

testTranslationNoFalseAliasConflict() in PathautoLocaleTest.php reproduces the exact scenario:

1. Creates an English node with alias /content/test-node
2. Creates a French node with the same alias (allowed cross-language)
3. Adds a French translation of the English node via the form
4. Asserts no "already in use" error appears

There are possibly related core bugs once the same alias for a different language has been saved on the same node. found #3179599: The same path alias cannot be set for two languages for that based on the title. Not exactly the same thing though.

It seems correct that the validation is meaningless if the checkbox is on as pathauto should ensure a valid alias.

The test looks a bit fragile to me because at the end it's just a negative assertion. This will still pass if for some reason the wording of that messages changes. It should assert that saving was successful and what alias was generated then.

@berdir, not sure to understand what should be done here.

Can you be a bit more precise?

You should always also have positive assertions (string X exists) and not just negative ones (string X does not exist), because those can easily pass when the string changes. Add an assert for the alias you expect to have and possibly the node save confirmation message.

Thanks, you're totally right, I'll fix that.

Test has been fixed. We should be ready to merge.

Fine. FWIW, the fact that core only has UI/form validation for this case and no validation constraint is a core bug that I recently saw discussed somewhere on Slack. It is possible that this will be added in the future and then this will fail again.