Hi,

I had massive problems woth pathauto on a International Travel Portal project, where I am fixing and programming stuff for.

I found out that, when I use i18n module with syncing CCK fields that when I change a translation the manually set paths of other translations get messed up even though I said:

Path Auto == no.

I investigated the problem and found out taht pathauto is not storing if it should process nodes, but rather detects it by examining current path and possible alias.

This information however is stored in pathauto_form_alter hook, but i18n does only do node_load, node_save and such node->pathauto_perform_alias is unset, which is interpreted by path auto to create an alias.

My fix is to add an additional variable to the form to decide if this node had been going through pathauto_form_alter and if in presave the field is not set I get back the old node and compute pathauto_perform_alias.

This way all works even if a module only uses node_load, node_save and the re-loading of the old node in presave should work and not introduce any slowdown as that one is still cached by the recent node_load.

Problem solved :-).

Patch is attached, please apply.

Best Wishes,

Fabian (LionsAd)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

greggles’s picture

Component: Code » I18n stuff
Fabianx’s picture

Assigned: Fabianx » Unassigned
Status: Active » Needs review

Set state to needs review as a patch was posted alongside with the bug report, so maintainer can see it :-).

Hello Maintainer :-).

Best Wishes,

Fabian (LionsAd)

anon’s picture

Title: Pathauto should not mess up aliases when node_load, node_save is used (i18n sync) » Pathauto should not mess up aliases when node_load, node_save is used
Version: 6.x-1.x-dev » 6.x-1.3
Component: I18n stuff » Code

This is a global problem, not just i18n.
Same problem when using webforms and it should be the same for all modules that use node_load and node_save.

anon’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
1.37 KB

Same as the first patch, but with one very small small change. (Indent not following the code standard)

Patch works fine!

Dave Reid’s picture

Version: 6.x-1.3 » 6.x-1.x-dev
Status: Reviewed & tested by the community » Needs work

This needs a test case to prove there's a problem and make sure we don't regress. Ideally this also needs a patch for 7.x first, which can then be backported to Drupal 6.

bibo’s picture

[Sorry for the lenght of this post]

i18n sync + pathauto creating unwanted aliases (that have been manually overwritten) have been a huge issue on a project I'm working on now. I'm surprised this issue isn't filled with complaints. Or maybe theyre hidden in other related issues?

Anyway, I'm using pathauto-dev (2010-June-29) with token-dev (2010-June-22) and i18n-dev (2010-June-10). (All are dev-version because of bugs that had to be fixed).
I did try this patch (had to insert it manually as it's outdated), but it didn't work as well as I hoped. It still creates duplicate aliases.

My site setup (to reproduce the scenario):

I have a page-type node that is synced to 3 languages: finnish, english, swedish. I've set a pathauto pattern of "[menupath-raw]". In some cases I need to override this (by unchecking "Automatic alias". Without the path the aliases were a total mess. An update of any of the nodes results in the 2 other nodes having new aliases created. However, in most cases the link to them seems like the alias was lost, so the language interface for example english => finnish version of the node, now leads to "node/123" instead of the alias! However, when I search for the alias at "/admin/build/path/list" I find it, in fact I find several duplicates of the same alias! This was probably somehow caused by my i18n content negotiation settings (and sync etc), that were activated during the node_save() of the translated nodes.

There were also special cases, that might be worth mentioning:
These 3 nodes (fi, en, sv) have the same title and menutitle (in my test case "Media", and thus happened to generate the same alias, just for different languages. That is, they resulted in;

/fi/media (also works without the fi-prefix, since it is the default language)
/en/media
/sv/media

Naturally I didnt save the language prefixes, the aliases are listed as simply "media" under node form and "/admin/build/path/list" . But I guess it works anyway, because of the language negotion, right?
When I tried changing the aliases manually to "media_en", "media_fi" etc, they seemed to work ok AFTER the path (but I dun wanna, "media" works better if the content language just works as it should).

However, still more confusion: I deleted all "media" aliases on the alias admin page (there were already a dozen!). Then I tried changing an alias. The result was: alias for that node works BUT, it says it created 2 aliases for the other synced translations! This I noticed only by the message that was displayed:

Created new alias media for node/203.
Created new alias media for node/609.
All 2 node translations have been synchronized.
Page Media has been updated.

...and even more confusion, node/203 and node/609 STILL seem to have no alias at all - which in theory is ok, I didn't want them to have aliases anyway! But they show up in the /admin/build/path/list - page! I believe this might be because those aliases are set to the wrong language (or maybe not?) .

In any case, all this mess would be solved if pathauto would just leave alias autogeneration disabled on node update _except_ if it's ensured that the node_save() was launched via node edit form and "Automatic alias" was infact checked. The patch almost does that but, it has checks that result it to activate the alias generation for translated nodes if they have no aliases yet.. Maybe it checks for the wrong language aliases? Some might even want this to work it this way.. so the users should be able to choose.

Maybe the settings at "admin/build/path/settings" with, or after, this:

UPDATE ACTION:
( ) Do nothing. Leave the old alias intact.
( ) Create a new alias. Leave the existing alias functioning.
(x) Create a new alias. Delete the old alias.

... should have on extra checkbox option that determines what happens on node_save(), or hook_node_api() $op=update to be more specific, outside of node form submitting context. Something like:

[x] Create a new alias only during node form submit, and alias bulkupdates, but not in other circumstances, such as external modules calling node_save().

I know this would affect many modules, so it might be unlikely to happen. It might be possible to do via a custom module.. But this functionality should really work out of the box.

[ I've attached the patch from #4 , and updated it so it should apply to latest pathauto-dev (2010-June-29). However, I'm NOT suggesting people to use it, it needs work.]

What would the proper solution to this? I probably need to find the correct issue where people are discussing this problem...

bibo’s picture

Component: Code » I18n stuff
Status: Needs work » Needs review

I looked for the alternatives earlier, and noticed there are other issues about this, some older. #358722: Node aliases lost/changed when using i18n synchronize translations for example has a patch that is very similar to what was suggested here (at #4).

It's also older, and it has more responses. So.. this issue is a duplicate I guess. Or is it? The patch in the order also hasn't been commited for lack of simpletests (dammit!). Is there some other issue that is the most current?

Status: Needs review » Needs work

The last submitted patch, pathauto.i18n_sync_fix_726964_for_dev-2010-june-29.patch, failed testing.

bbenone’s picture

I've been tracking this issue for a while now as well. I've been following a few threads which seem to relate, but this is the closest one I have seen to my specific problem.

Given the number of issues out there, I think that pathauto and i18n are just in general not friendly with one another.

I tried this on a clean install tonight. Here was my test case:

Drupal 6.17 + i18n 6.x-1.5 + pathauto 6.x-1.3

(1) I create a plain page node, in English, with a manually set path of: about/qualifications
(2) I click translate, and click the link to add a Spanish translation
(3) On the node creation screen, I uncheck auto alias, and give the new node a path of "about/cualificaciones"
(4) Then click save

The new node, Spanish translated, has the correct path "es/about/cualificaciones" (good)
The old node lost it's path and is now using an automatically generated default alias "content/qualifications" (bad)

I'll try to monitor the dozens of potentially related threads and retest if something happens. If anyone sees movement (in the form of a testable patch) in one of them please post here as well, and I'll give it a shot with my use case.

Thanks...

bbenone’s picture

FYI, pfournier has isolated why this is occurring here:
#269877-202: path_set_alias() doesn't account for same alias in different languages

It's unrelated to the D6 core patch being discussed in that thread (to path.module), so this issue is unlikely to be addressed by anyone there. But it looks like he has isolated what's going wrong, so it may be a good head start for anyone wanting to patch this.

Dave Reid’s picture

Status: Needs work » Closed (duplicate)
palmaross’s picture

Status: Closed (duplicate) » Needs review

#4: pathauto.module.patch queued for re-testing.

Dave Reid’s picture

Status: Needs review » Closed (duplicate)
astro75’s picture

I don't think this is pathauto problem. Multilanguage path alias mess up without pathouto installed. Only Path and CCK Synchronization. All aliases become assigned to main language.

ikeigenwijs’s picture

I have the same problem, and after 1 week of surfing this is the closest to my problem, but its still no solution.
I have to finish this site in 1 week.