Scenario:
1.Node is translated into several languages (with the same URL alias),
2. User is reverting revision for one of the translations or for the origin node.
Problem:
URL aliases are deleted on all the translated after reverting the revision.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sunwarior’s picture

Status: Active » Needs review
gnindl’s picture

Title: Translatable nodes problem » Translatable nodes problem with same URL alias
Status: Needs review » Reviewed & tested by the community

I encountered the same problem when using the i18nsync module. When I want to add a translation with the same alias - which results in a language configuration "Path prefix" in "alias" => "language/alias", e. g. "documents", "es/documents", it simply failed. In the url_alias table I'd like to achieve something like this:

pid src dest language
1 node/1 documents en
2 node/2 documents es

The current update statement (see patch) ignores the language alias and simply overwrites it. For example if I save the Spanish node, the Spanish AND the English node alias are set, the same the other way round. When I save a node with i18nsync on, a save operation for all other translated is triggered resulting in this flaw.

It can be argued that this is a i18nsync bug, but I think that URL alias should support multilingualism. As I understand there are no severe side effects.

Subscribing to this patch!

pfournier’s picture

klonos’s picture

subscribing...

klonos’s picture

Does the patch from #0 complement the one(s) at #269877: path_set_alias() doesn't account for same alias in different languages or does it conflict? I guess what I am really asking is if this is a completely new approach to the issue(?).

pfournier’s picture

Patch from #0 conflicts with the one in #269877: path_set_alias() doesn't account for same alias in different languages. Patch #0 solves the problem in an incomplete way. If you use i18n_sync + pathauto, you'll need http://drupal.org/node/269877#comment-3381420 and http://drupal.org/node/358722#comment-3347984.

klonos’s picture

@pfournier: Patrick, what do you think about this http://drupal.org/node/358722#comment-3391912

Can you please leave a comment with your thoughts there comparing that solution to this one? Thanx in advance.

pfournier’s picture

@klonos: I did not test this patch. I am using patch #40 (http://drupal.org/node/358722#comment-3347984); as noted in #47, this patch, however, will cause node created programatically to not have an alias generated automatically.

What we really need is pathauto to remember the state of the "Automatic alias" checkbox for each node.

klonos’s picture

I think there was an issue for that somewhere...

klonos’s picture

stupid me! it's #358722: Node aliases lost/changed when using i18n synchronize translations

[off-topic] ...Frankly, with all these issues concerning node translations and multilanguage sites, I get lost! So many patches to test/maintain it is easy to get one frustrated :/

I am seriously thinking of opening a new master-issue with all proposed solutions, same way it is done here: #849420: Cumulative Nested Fieldgroup Patches in order to keep track of CCK fieldgroup/multigroup. It's a real shame that drupal.org does not support issue relationship/dependency yet. I really loved the way you could even have that presented in a tree in bugzilla (see attached screenie).

blaiz’s picture

Subscribing.

akaliel’s picture

FileSize
1.7 KB

I used the patch from #0 and found that it worked to what I needed. For the project it didn't have the pathauto module but when batch updating nodes, it still had this issue causing aliases of all languages to be overwritten.

I also had a problem with batch deleting though, which would delete all aliases of the same destination instead of just the one for that language. To solve this issue I added to the patch from #0.

Morpheu5’s picture

Hi. The patch at #0 seems to have saved my day. If you ask me, I'd push it to the next release :)

sebos69’s picture

+1 here too for pushing it to the next release!

sanderc’s picture

(edit: Thanks, the patch worked for me too! Critical to go into the next release.)

I stumbled upon the same issue, but it is a bit different in my opinion.

When saving a translation of a node with a path that already exists, the path is ignored and the systempath (e.g. node/[nid]) is used when I view the node. When visiting /admin/build/path after submitting a translation, the path to the source-node is doubled in the URL aliasses list (see image). It seems the language is not taken into account when saving the URL alias for the translated page; the same language as the source-node language is used.

I can fix this manually, by altering the language of the duplicated URL alias manually, but this is not ideal, because in my system not all roles can administer paths.

When I update a translated node, the whole trouble starts again: the URL alias is altered/deleted by Drupal, and has to be manually set back to the right language.

Apart from this issue, it would be nice to have a general setting in Drupal where can be specified how Drupal handles paths with a multi language setup.

kscheirer’s picture

Priority: Normal » Critical

Same problem as described in the initial post, and the provided patch applied to D6.19 and worked like a charm. Patch in #0 is RTBC from me as well. Did not test patch in #12.

As noted in this issue several others, there seem to be a few tricky bugs in the interaction between path, pathauto, and the various i18n modules. Getting core path fixed up would help a lot. Bumping to critical to put it on the radar for next release.

longwave’s picture

Project: Path » Drupal core
Version: » 6.x-dev
Component: Code » path.module
Priority: Critical » Normal

Reassigning this to Drupal core, where it should get more attention.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, path_alias_2.patch, failed testing.

kscheirer’s picture

Status: Needs work » Needs review

path_alias.patch queued for re-testing.

kscheirer’s picture

Priority: Normal » Critical
Morpheu5’s picture

As far as I can see, patch #0 is not in 6.20, though it seems to me it can be applied. Patch #1 looks more complete and, as I'm not familiar with the testing facilities here at Drupal.org, I can't see why it's "non-applicable".

Can anybody clarify this to me? I'd really like to (help|see this patch committed) :)

Morpheu5’s picture

#12: path_alias_2.patch queued for re-testing.

Morpheu5’s picture

path_alias.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, path_alias_2.patch, failed testing.

Morpheu5’s picture

FileSize
1.74 KB

Manually corrected the patch. It works for me with

drupal-6.20 $ patch -p0 < path_alias_2_0.patch

Submitting for retesting, at least it should be applicable, now.

kscheirer’s picture

Status: Needs work » Needs review

testbot will only check when the status is "needs review"

Status: Needs review » Needs work

The last submitted patch, path_alias_2_0.patch, failed testing.

longwave’s picture

Testing core patches only applies to D7; as this is a D6 issue, testbot will always fail.

klonos’s picture

I honestly didn't know that. I thought that the testbot run against whichever major version of core the current issue was assigned to. Is there a request for that someplace?

Morpheu5’s picture

Status: Needs work » Needs review

Sorry, I didn't now about both the "needs review" and the D7 thing.

Further instructions would help. FWIW, the patch works like a charm for me.

kscheirer’s picture

Does this bug still exist in Drupal HEAD? If so, we need to fix it there first.

kscheirer’s picture

[deleted double post]

Morpheu5’s picture

I'm not sure what you mean by HEAD, since I think it's for D7, not D6.

FWIW, the bug is still in DRUPAL-6-20.

kscheirer’s picture

HEAD is the current development version of drupal.

sebos69’s picture

The patch fixes the issue for drupal 6.20, thanks!

/me scratches his head wondering why the patch was not included in the drupal update...

kscheirer’s picture

Patches go into the latest version of Drupal that still has the problem.

So we need to document whether this is a problem in Drupal's current development version (called Drupal HEAD). If so, we patch it there and backport it. If not, we check Drupal 7. If its a problem there, we patch it and backport it. If not, we can say this is a Drupal-6 only bug and the patch will be accepted.

We don't even have to worry about the backporting, often the branch maintainer will handle that part.

klonos’s picture

Title: Translatable nodes problem with same URL alias » All aliases get deleted/overwritten when translatable nodes with same URL alias are reverted to previous revision or updated

...title edit, so that it describes the issue better.

druplicate’s picture

Version: 6.x-dev » 6.20

I have a similar problem with assigning the same URL alias pattern using taxonomy tokens. The token translation is different per language but the path module over writes the other language's aliases on save. Only the alias pattern is identical: paris/[field_area_select-term-raw]/condo/[title-raw]

The patch in #25 did not fix this problem.

To test this I only translated one taxonomy term in [field_area_select-term-raw].

If I save a node in Russian I get for example: example.com/ru/russia/Москва/condo/19771
Then if I change the site language to English it overwrites the alias as: example.com/russia/Москва/condo/19771
It also overwrites every other translation's alias with the same Russian token.

After a lot of sleuthing I traced this to the Translation Synchronization module. If you have ANY field marked for syncing this problem occurs. Uncheck all sync fields and it behaves normally.

There are at least a dozen issues related to this, some with hundreds of posts going back several years across numerous core upgrades. Tried installing the Pathauto Persistent State module but it didn't fix this.

What a mess.

roderik’s picture

Title: All aliases get deleted/overwritten when translatable nodes with same URL alias are reverted to previous revision or updated » All aliases get deleted when translatable nodes with same URL alias are reverted to previous revision
Status: Needs review » Needs work

This issue has morphed.

The first patch is now obsoleted since #269877: path_set_alias() doesn't account for same alias in different languages was committed to D6.23.

The 'deletion' part, introduced in #12 by akaliel, was not included in that commit. (As the issue was too confusing already.) So that still needs to go in.

Back to CNW, for deleting the first of 3 hunks from the patch, and keeping the other two.

marinex’s picture

Hi roderik, I manually applied the 'deletion' part from patch #12 is it right? May I apply "path_set_alias($path, NULL, NULL, $language);"? Thanks M.

roderik’s picture

As far as I can tell, yes you should also apply the last "path_set_alias($path, NULL, NULL, $language);".

I haven't tested this, really. I came over from #269877 and thought I'd just comment, to make the current issue clearer.

(I thought I'd seen another issue w.r.t. this "All aliases get deleted", half a year ago, but can't find it anymore... #481706: Path_node_delete can leave abandoned URL aliases seems related though, maybe that could be rolled into one patch with this issue. I wish you success in testing.)

marinex’s picture

@roderik: Thanks for help

Status: Needs work » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.