Book & Menu paths tokens not calculated for the translated nodes

Sorry. I don't use the i18n module and I don't have any ideas, so I can' t help with this.

Maybe Freso can, but I don't think he uses i18n either.

This sounds rather weird. What other (node) alias patterns have you set up?

It seems that this occur when i18n synchronize translations...

After making some investigations I found the following:

1. This happens when i18n synchronizes the translations of the main node (which is being saved). The function i18nsync_node_translation() from module i18nsync (from i18n) saves also the translated nodes, using node_save().
2. When node_save() is applied on the translated nodes, he ask all modules to act on the node update. And so Pathauto module is recreating the paths for the translated nodes.
3. Pathauto is calling the Token module to build the the path's tokens.
4. In functions node_token_values() and book_token_values() from token_node.inc, the Token module is calling for _menu_titles() to get the trail to the current book page (or the menu trail for the current node).
5. _menu_titles() uses the menu_tree_all_data() function to obtain the hierarchy data for books and/or menus.
6. The problem is that menu_tree_all_data() is returning no data when is called second time in the same request. And so _menu_titles() is returning an empty array that causes empty paths for [bookpath-raw], [bookpath], [menupath-raw] and [menupath] tokens for the second and next nodes saves in the same request.

Affected tokens:

• [bookpath-raw]
• [bookpath]
• [menupath-raw]
• [menupath]

Related issues

• #311688: Pathauto only generates correct urls for english pages

Actions taken:

• Moved the ticket to Token module
• Changed the title

Digging more, I found that this is fired up by a line in menu.inc Drupal core file. In line ~970, function menu_tree_collect_node_links() we have:

      if (is_numeric($nid)) {
        $node_links[$nid][$tree[$key]['link']['mlid']] = &$tree[$key]['link'];
        $tree[$key]['link']['access'] = FALSE;
      }

You can see there that the access of the menu item ($tree[$key]['link']['access']) is set to FALSE. This is causing menu_tree_check_access() [called from menu_tree_all_data()] to exclude the item for menu trail.

It would have been desirable that function menu_tree_check_access() to set the proper access value... but it doesn't.

I hacked the Drupal file menu.inc as in the attached patch and now the paths are built fine on my site...

If you want to use the patch keep in mind that this patch is a Drupal core patch and can break other things on Drupal. Some testing and inputs can be valuable... Maybe some guys that designed the new Menu system can explain more here...

Is this related ? #242601: translate node references with i18nsync The patch is for 5.x

I disabled the synchronization for now to not to update the translated content.

In my experience of this bug, with any synchronization the url aliases to the translated nodes (not the one being saved) get completely wiped out, not only modified, as davebv reported.

Did as humble.techy and disabled all synch. Pathauto works fine then.

I'm almost sure that this bug is caused because the items of the menu system that are in other language than the current language have the access property set to FALSE. This mean that when i18nsync tries to recompute the paths for the non-current-language menu items he cannot access them for read. This is causing the failure of getting the trail for the non-current-language menu items. This a by design issue.

My opinion is that this is a wrong approach to hide non-current-language menu items. The multilanguage system MUST NOT use access flag to hide those menu items. If they are in other language this DOESN'T MEAN that the user is denied to access them. It only means that they are hidden to user. A new flag must be used to hide other language menu/book items. Maybe something like hidden.

We need a qualified input here from developers of menu system and of the i18n on this issue!

Moved the issue to Internationalization module while is related to translated menu items and i18nsync.

It seems this issue has moved around a lot of modules. And while it's a side effect of how they all work, it's not really a bug on any of them

@claudiu,
I think you've made a great analysis of this issue in #8 and #13
I completely agree about the menu system issues.

As patching D6 core is not really an option and there's very little we can do on i18nsync alone, I think the better solution would be either:
- Not doing any path aliasing that depends on the page context (I can imagine this will fail too with any other module using node_load / node_save in a different page than node/x/edit.)
- Implementing some way to skip recalculating path aliases on node update. Though this may be an issue too because these paths may may actually need to be recalculated based on the updates done by i18nsync (tags, etc...)

Ideally, doing a node_save(node_load(nid)) should never change a node... Could this be a feature request for pathauto? If you find other contrib modules doing node updates using the api, maybe...

Btw, if someone wants to do some more research, what happens when you update several nodes at once using the content administration pages? does pathauto works fine on this case with such tokens?

@claudiu.cristea: isn't there a typo s/return/result/ in the patch posted in comment #9 ?

BTW, I also have this one triggered by pathauto with alias pattern for pages set to [manupath-raw].
I am sure your patch will work ok, but I read here this can be worked around also disabling i18nsync, well, I have it disabled in the module list, but the issue is still here, any more steps? Or patching core is the only viable option for now?

Thanks,
Antonio

Please do not use that patch... It's not solving the issue

@Jose,

Don't you think that this must be addressed now in D7 branch? As I mentioned and you agreed "non current language menu items" are hidden now based on the access. This flag is set to FALSE for those menu items. Being in other language doesn't mean unaccessible, it just mean hidden. If we want to access them, we cannot... And, yes, we surely want at least in i18n_sync module.

For this reason I think that we have to contact the menu system developers and fire up this issue and fix this in Drupal 7. My approach it would be to add an additional field (flag) to menu items, something like visible (boolean) that can be used by modules like i18n to hide menu items... (and not to make them inaccessible).

Any thoughts?

Changed also the status.

subscribing

Subscribing.

Subscribing.

Appears to be a 6.x issue.
Closing;
Please see :
#1303518: Clean up the issue tracker. Close old issues without follow up.