On multilingual sites, Drupal does not reliably respect an explicitly specified path alias langcode when saving a node, for example.
If code sets the path field langcode to a language-neutral value, the saved alias may still use the node translation language instead. Updating only the alias langcode may also be ignored.
This makes it difficult to create language-neutral aliases programmatically when the intent is for one alias to work across languages.
LanguageInterface::LANGCODE_NOT_SPECIFIED.Expected result: The saved alias uses the explicitly provided alias langcode, including a language-neutral value when intended.
Actual result: The saved alias falls back to the node translation language, or a langcode-only change is not persisted.
Respect the alias langcode set on the path field during alias create and update operations, instead of always deriving it from the node translation language.
Here is the case:
One website has two languages enabled. English and French.
If user who uses French as his/her language post a node, set node url alias, the url alias will only apply to French interface. That means the alias link wont work for those users using English.
The solution is to change the 'Language' value of that node's url alias to 'All' (admin/config/search/path)
I found it is annoying, because I have to change the Language value one by one for every node.
Not sure it is a feature or a bug?
That would be great that if when we set url alias for nodes, the system set it for ALL language by default.
What do you think? Any suggestions?
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 1499532-alter-node-alias-language-d7-do-not-test.patch | 4.74 KB | q0rban |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !15411
Comments
Comment #1
Alessandro Pezzato commentedThis is very annoying.
Suggestion
Add an option in admin page "admin/config/search/path/settings" to configure this behaviour:
If "All languages" is selected, every created alias will be available for all languages.
If "Node language" is selected, every created alias will be available only for respective node.
Comment #2
spacediver commented+1 For Alessandro suggestion. Or there is another way to fix it?
Comment #3
q0rban commentedI did some digging into the code in Path module, and there is no clean fix for this in contrib or custom code. While the form itself does have the path language set, overriding it with a form alter does nothing, as the language is then set to the node language in both the element_validate callback, and the hook_node_insert/update calls. I'm not sure why it's happening in both—I think this is cruft.
Comment #4
q0rban commentedI'm switching this to a bug report and changing the version to 8.x. The reason I believe this to be a bug is that there is no way to programmatically set the language on the alias, as the language is forced to match the node language in hook_node_insert / hook_node_update, ignoring what might be set in $node->path['language'].
Comment #5
q0rban commentedHere is a patch with just a test to prove the issue.
Comment #6
q0rban commentedAnd here is a patch with the above tests and a fix. Note: there was a fair bit of duplicate code in path_node_insert() and path_node_update(), so I refactored the latter to allow for being called from the former, to consolidate the code.
Comment #7
q0rban commentedHere is a patch against 7.x that does the same. Marked as do-not-test.
Comment #8
q0rban commentedI was hoping that applying this patch in d7 and adding a form alter like so would fix my issue:
Alas, Pathauto also doesn't respect $node->path['language']. See #1155132: Add Entity Translation support to Pathauto.
Comment #9
q0rban commentedRelated Pathauto issue here: #2030983: Cannot programmatically specify entity path alias language
Comment #12
damienmckennaAny thoughts on how this should work, given there have been two years' of changes since the last patch?
Comment #19
Chris CharltonBump.
Comment #28
smustgrave commentedThis came up as the daily BSI target.
First is this still an issue? Checking the patches that hook appears to have been renamed in https://git.drupalcode.org/project/drupal/-/commit/81e2d9c05107138a6cdbf...
If still an issue can we update the summary please
Thanks.
Comment #30
joelpittetThis is an old one(of ∞) I was watching, the code drift is big! We don't use
$node->path['language']it's$node->path->langcode.I opened an MR to try and see if I can get some of the intent behind the patch in #6 into something usable and an issue summary rewrite from the "support question" to the standard template.
Disclosure: AI was assisting me with finding the drift and I am the human-in-the-loop reviewing and rewriting this as it goes. I am happy with the changes made here, questioned the extra condition and new marker variable for tracking "changed" in either case. Ran the tests with and without the fix (which I will do in the MR too) to show the red 🔴/green 🟢. I know AI can seem like slop and we are all dealing with this huge change in our own ways, though I am hoping to show it can be used responsibly as an assistive tool... I am really liking ghostty's AI policy btw, worth a read, a bit extreme but clear.
Comment #32
smustgrave commentedTest coverage does appear to be present https://git.drupalcode.org/issue/drupal-1499532/-/jobs/9307242
Test manually following the steps.
Fresh Drupal install
2 languages (I used Arabic)
I ran ddev drush php:eval "$node = \Drupal\node\Entity\Node::load(1); $node->path->langcode = \Drupal\Core\Language\LanguageInterface::LANGCODE_NOT_SPECIFIED; $node->save();"
I couldn't figure how to trigger this bug via the UI so I then ran
ddev drush php:eval "$node = \Drupal\node\Entity\Node::load(1); echo 'Langcode: ' . $node->path->langcode"
And I did get en
But with the MR I get 'und' which sounds like the fix.
So would say this works.
Comment #33
quietone commentedI updated credit and didn't see any unanswered questions.
Comment #37
amateescu commentedCommitted and pushed f30d64c5689 to main and a5b927148fb to 11.x and 6c3a9c494ee to 11.4.x. Thanks!
I also ran the Pathauto tests and no problem came up.
Comment #40
berdirYeah, I explicitly didn't want to support this in pathauto until core is handling this better. There's also #2689459: If you don't want to translate your URL alias, the original URL alias won't work with your translations which I think has some overlap with this issue, commented there.