The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.We're finding that whenever the language source node is edited, the language of the menu item changes from 'All languages' to the language of the source node (English in our case) and an additional menu item is added to the same menu. The 'Enable node translation' setting also disappears in the menu item settings throughout the translation set.
This is similar to the issue noted here - http://drupal.org/node/917896 - but we're not using i18n_auto.
Thanks in advance for any help or advice!
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | i18nmenu_node-set-weight-1543910-1.patch | 757 bytes | remydenton |
| #4 | i18nmenu_node-set-weight-1543910.patch | 487 bytes | remydenton |
Comments
Comment #1
remydenton commentedI'm working with az100sun on the same project where we're seeing this issue and just thought I'd add some more information.
It looks like the problem is happening in the 'presave' part of the i18nmneu_node_nodeapi() function, where $node->menu['language'] gets unset (line 477 of i18nmenu_node.module). Actually, this part works fine, but the problem is that the hook_nodeapi() implementation in the Menu Translation module runs after this and resets the menu language (line 427 of i18nmenu.module -- we're using 6.x-1.10). If we comment out line 427 of i18nmenu.module, this bug disappears, at least as far as we can tell.
It seems a little unlikely to me that this wouldn't have been reported already if it were that simple, but maybe this will help with the diagnosis. Thanks in advance.
Comment #2
remydenton commentedOkay, I think we've gotten to the bottom of this. It looks like the nodeapi hook is meant to be called first from the i18nmenu module, then from i18nmenu_node. Though they have the same weight, this would happen on most sites since 'i18nmenu' comes before 'i18nmenu_node' alphabetically.
The problem in our case is that we had the two modules in different directories: sites/all/modules/contrib/i18nmenu_node and sites/all/modules/patched/i18n/i18nmenu (we had applied a patch to an unrelated part of the i18n module). As it turns out, the entire path is actually used in the alphabetical sorting, so since 'c' (contrib) comes before 'p' (patched), the functions were running in the wrong order.
Definitely a bit of an edge case, but it still feels like this is ultimately a bug. Would it make sense to give the Menu Translation (Node) module a weight of 1 to make sure it runs after the main Menu Translation module?
Comment #3
plachYes, altering the module weight should do the trick.
Comment #4
remydenton commentedOkay, here's a little patch to do just that.
Comment #5
stevenovy commented...and voila! It works!
We were able to replicate the issue in a local environment with i18n and i18nmenu_node in different directories. We ran the patch in #4 against i18nmenu_node, ran update.php, and it works great. Many thanks to remydenton!
Comment #6
plachWe need to perform the weight alteration also on install...
Comment #7
remydenton commentedAh, good point. Updated the patch to set the weight on install as well.
Comment #8
plachCommitted and pushed, thanks.