Problem/Motivation
Currently the code in entity_translation_pathauto_alias_alter()
pretty much forces the re-creation of the path alias of entity translations without respecting the pathauto state.
One problem here is that pathauto doesn't properly support language aware pathauto states - not yet at least: #2614736: Store alias language in pathauto_state table
However, there's already a way to determine if a translation has the auto generation of aliases enabled.
Btw. this seems to be a regression as this behaviour was supported before the entity_translation_pathauto_alias_alter()
handling was expanded.
Proposed resolution
Re-use the approach from pathauto_field_attach_form()
to detect the state as long as pathauto_entity_state_load()
isn't language aware.
Sidenot: this legacy approach has to be kept to be backward compatible anyways.
Use reflection to check if pathauto_entity_state_load()
supports language aware states.
Remaining tasks
Reviews needed.
Work on #2614736: Store alias language in pathauto_state table.
User interface changes
None
API changes
None
Data model changes
None
Comments
Comment #3
das-peter CreditAttribution: das-peter at Cando commentedFixed undefined index in refactored code.
Comment #5
isa.belHello,
I had the same issue, and entity translation was overriding the alias for all languages.
The steps I did to reproduce the issue was:
1 - Create a node using the default language.
2 - Add a translation and save.
3 - After saving it, the alias created previously (using the default language) was being override by the alias created on the translation.
And it happened every time I saved the node, no matter which language I used neither how much translations I had, all aliases was being override by the latest.
I thought it was a pathauto issue, but after debugging it, I've found out that it was happening because the function
entity_translation_pathauto_alias_alter() didn't have any condition to see if the path should be replaced.
This patch worked for me. So thank you very much!
Comment #6
stefanos.petrakis@gmail.comThank you both for the information, I have been thinking and working on this for a while now;
it seems to me that there is a big overlap with what is happening over at #3010146: Expose extended ET-specific configuration for pathauto
@das-peter: You are right, this came in when #2743685: Pathauto update for all translations for a single node got commited. I had a first look at the code and find the Reflection approach intriguing. I would like to first move forward with #3010146: Expose extended ET-specific configuration for pathauto and following that see what needs to be addressed from this issue here. Hope this is fine with you, appreciate the help very much.
@isa.bel: Your issue is a consequence of changes from #2743685: Pathauto update for all translations for a single node, apologies; there are more options available with the patch at #3010146: Expose extended ET-specific configuration for pathauto; a site administrator could now define that creating a new translation only creates an alias for the active language, which would allow you to circumvent the problem you were facing.
Comment #7
stefanos.petrakis@gmail.comSince #3010146: Expose extended ET-specific configuration for pathauto got commited, it seems that this issue can be resolved via configuration.
@das-peter: Could you confirm this?