Node edit page shows menu item (for node being edited) in all languages

I'm also experiencing this issue after the upgrade. Specifically, end users would see this menu issue when editing organic groups content on our site.

I also had this issue.

How I solved it:
* (not sure if necessary) Change the menu translation mode to "fixed language"
* Checked my menu items, they still had 'language neutral', so I had to re-save the node on which the menu item is created on.

I could reproduce this error too, but the doubled menu items (we have EN and DE) only occures in edit modus of a node.

The menu items were correctly signed with the language, so changing between fixed or the other options did not help. Maybe it helps if you create a menu for each language with the option fixed.

I'm also experiencing this issue after the upgrade to the last release of i18N on all node edit pages.

I have reproduced this issue on a fresh install on my laptop with : Dupal core 7.27, Variable 7.x-2.5 and Internationalization 7.x-1.11. Translation mode is fixed to "Translate and Localize. Menu items with language will allow translations. Menu items without language will be localized".

Can anyone please post a detailed description on how to reproduce this issue from scratch on a fresh drupal+i18n install?

@ FeanorCC Removing that code will introduce another issue, it can inadvertently disable menu links on all pages as mentioned in #1693074: Change menu translation approach (i18n_menu_translated_menu_link_alter() skips item subtree processing)

To reproduce this issue from scratch :
- install Drupal 7.28 (en version) and enable Locale and Menu
- install Variable 7.x-2.5 and enable Variable
- install Internationalization 7.x-1.11 and enable Block languages, Internationalization, Menu translation, String translation, Translation sets
- Add a new language (fr) at Administration » Configuration » Regional and language
- Edit the main menu and set Translation mode to "Translate and Localize. Menu items with language will allow translations. Menu items without language will be localized"
- Add to the main menu some menu links in english (en1, en2, ...) an french (fr1, fr2, ...)
- Add an Article node

This patch should fix things, while still solving the menu links disappearing when a node is being edited (there is an automated test for this as of #1693074: Change menu translation approach (i18n_menu_translated_menu_link_alter() skips item subtree processing)).

The underlying issue is with Drupal core though (see #2136815: hook_translated_menu_link_alter also runs upon editing nodes with menu links, not just upon menu link display).

Tests seem to have passed, can you guys please confirm this patch solves your issue?

The patch works for me too

Thanks, can anyone review the code as well?

What this does is it makes sure the hooks intended for display (ie whether to hide a menu link or not) are not run when editing the menu link associated to a specific node through the node edit form.

This worked for me as well. Thanks for the patch!

This patch worked perfectly for me.

Thanks for the patch stefan.

Code looks good and works well here.

Committed, thanks.

Patch is working, thank you...four hours to find where it came from ARF !

The patch is not working completely.

Before applying it I had all the menus displayed in all the languages when I was on a node/*/edit page.
After the patch, when I am trying to edit a node that is placed as a "parent" menu item, I will still get that menu item showed in both languages.

Removing that portion of code, as FeanorCC mentioned, fixes the problem, but I don't know what issues might that cause.

I added a patch that fixes the issue.

Hmm good spot, not sure what an easy solution would be here. I think the patch in #25 will still break things elsewhere.

Updated title to clarify that this only affects the menu item for the node being edited anymore.

#6 worked for me, thanks!

Attaching patch based on #25 that will work for my drush make using i18n v1.11.

Installing the latest dev version fixed this issue for me thanks :)

This patch still has the issue pointed out in #29, it'll introduce other bugs as it won't just affect the link being displayed.

Setting to needs review so as to see if it passes tests.

#9 Fixed for me with no apparent problems elsewhere (I am using both i18n and Entity Translation, and I both have translated and localized menu links).
Thank you so much stefan (I was sick of this!)

Issue is solved for edit node by this patch Thanks stefan:)

I was seeing every menu in EN and ES on edit of any page.

I installed the latest version of i18n (dated June 2014) and it is working on most nodes. The parent nodes are still showing both languages for its menu items on edit page. Same as #29 vdanielpop mentioned. This is better than seeing EVERY En and ES menu item, but not ideal.

I then reverted to i18n 7.x-1.11 and tested patch in comment #31. That seemed to fix the entire problem. I'm not sure why it is failing the automated tests (I'm not familiar with the testing process). But so far it works for me!

I also tried both i18n 1.11 + patch and most recent dev

Both seem to solve the problem of displaying menu items of all languages

@hwasem and others, the patches in #25 and #31 fail tests because they introduce a previous bug: they can change a menu item to be disabled if the language of the menu item doesn't match the node language, when it had been explicitly set to be enabled before. See #1693074: Change menu translation approach (i18n_menu_translated_menu_link_alter() skips item subtree processing)

Hello,

Here is a small patch for a hot fix from 7.x-1.11

#40 worked for me !!
Thank you : )

#40 is the same as #25 which fails tests. As mentioned in #39 this patch will introduce other undesirable behavior.

@yce this patch will keep failing tests until it is fixed, it needs to address the issue in #1693074: Change menu translation approach (i18n_menu_translated_menu_link_alter() skips item subtree processing) to pass tests :)

Rerolled #31 (which is the same as #9 + #40) to latest dev.

I really should just change the status when adding a patch...

Looks like the patch failed testing after you changed the status to "Needs Review" so I manually applied the patch to version 1.11 and appears to be working as expected for the node edit form, however I still see all menu links in all languages when looking at the "List Links" page for one of my menus- but only one of my 12 menus.

Tests fail because applying this patch introduces a new, more severe issue: #1693074: Change menu translation approach (i18n_menu_translated_menu_link_alter() skips item subtree processing), ie it can cause Menu links to become disabled while editing a node.

Hello,

i have encountered the same problem in my multilingual site with synchronised nodes (synchronised fields).
If I synchronises the datas between nodes, the node source is saved in the language of interface. But the translated node is synchronised and saved in the same language. Then, my menu item is disabled.

I have tested several patchs without success. The patch who seems to work is the path #6.
In the last dev version (7.x-1.11+13-dev) the patch inserted is most recent (#48 ?). This dev version is not functional for me and for the synchronised nodes.

Hello,

If we use the "Synchronize translations" option in a content type, we get a "disabled menu item" when we save a node in other language. Because the nodes are saved in the same admin interface (see above). If we not use the synchronization, there is no problem.

I have found a solution and modified several lines in the i18n_module. Maybe it's a dirty solution, but it's functionnal if we create or modify a translated node.

    // Skip if administering this menu item through the node edit form.
    elseif (arg(0) == 'node' && arg(2) == 'edit' && $link['link_path'] == arg(0) . '/' . arg(1)) {
      return FALSE;
    }
	// Skip if administering this menu item through the node add form / creation of the translation
    elseif (arg(0) == 'node' && arg(1) == 'add') {
      return FALSE;
    }
	// Skip if administering this menu item through the node edit form / edit a translation
    elseif (arg(0) == 'node' && arg(2) == 'edit') {
      return FALSE;
    }

Perhaps we can add a condition if the content type uses a synchronization....
Think you that the code in the i18n_module was fixed or if this code can be modified? (to take the synchronization)

Thanks for your help.

P.S. I use i18n 7.x-1.12

i18n 7.x-1.12 Is working for me.

Hello RajabNatshah,

in your content types the fields are synchronized ? Do you use Entity Translation with i18n ?

Thanks.

Thanks kum :)

I do use it for some entities, ( Users, FPP, Bean ).

Rewarding work :)

This patch still fails tests and re-introduces the issue in #1693074: Change menu translation approach (i18n_menu_translated_menu_link_alter() skips item subtree processing)

Maybe another way to fix this would be to fix in core (see #2136815: hook_translated_menu_link_alter also runs upon editing nodes with menu links, not just upon menu link display).

A related issue is also introduced by #9: #245509: WAV files

This would rather be fixed in core though -- if hook_translated_menu_link_alter only ran on interface elements (and not on form widgets or links being submitted), this issue would be solved as well.

Hello,

For me and with the lastest version (7.x-1.13) the bug persists.
This code don't resolve the bug of the desactivated menu items:

elseif (arg(0) == 'node' && arg(2) == 'edit' && $link['link_path'] == arg(0) . '/' . arg(1))

If I change the code with this, it's ok for me and I have no problem.:

elseif (arg(0) == 'node' && (arg(1) == 'add' or arg(2) == 'edit'))

The "add" argument is necessary if we save (and translate) the node from the translation page (node/*/translate?destination=admin/content).

But, if we have a field collection in the content, we have again a problem. If we edit directly the fc by his "edit" button" and save it, the above code has no effect. We must change this code with a new condition for the edit page of the fc (/field-collection/field-paragraphs/*/edit?destination=node/*...).

Can we solve this problem via this code and with more conditions? Or by another method?

Thanks.