Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I am using the i18n module (with all submodules activated incl. Menu Translation).
My default language is german (without prefix). English is the second language (en as prefix).
Menu Block is working with default language but if I am switching to the secondary language then the block dissapears. Everything else on the site is working fine, only Menu Block seems to be affected.
working:
www.domain.com/produkte/title
not working:
www.domain.com/en/produkte/title
thanks in advance!
Comment | File | Size | Author |
---|---|---|---|
#15 | menu_block_translation_fix.patch | 1.08 KB | Chandan Chaudhary |
#6 | menu_block_1691450_v2.3.patch | 824 bytes | andreiashu |
#5 | menu_block_1691450_2.patch | 849 bytes | andreiashu |
#4 | menu_block_1691450_1.patch | 646 bytes | andreiashu |
#1 | menu_block-18n_prune_fix.patch | 1023 bytes | drupalninja99 |
Comments
Comment #1
drupalninja99 CreditAttribution: drupalninja99 commentedI have struggle with menu blocks that follow the active menu tree bc the menu prune function in menu_block does not work with i18n_menu in drupal 7. So I created a small patch that forces the menu_tree_prune_tree() function to lookup the source node id when it's checking to see if the current page is in the active trail.
Without this patch for translated nodes it will never work and also return nothing. I don't think this is a problem for view pages, etc. other pages that don't change their paths like nodes do. This patch works great for me, the menu gets pruned as expected.
Comment #2
Goekmen CreditAttribution: Goekmen commentedThanks for the patch, meanwhile I uninstalled Menu Block and used the Context Module.
But good to know for future projects :-)
Comment #3
andreiashu CreditAttribution: andreiashu commentedHi and thanks for the patch.
Unfortunately the patch from #1 only works for 1 level items. Also I don't think its place is in
menu_tree_prune_tree
function. I still need to investigate but this definitely needs more workComment #4
andreiashu CreditAttribution: andreiashu commentedAttached patch is against 2.x-dev. Let me know if it fixes your problem.
Comment #5
andreiashu CreditAttribution: andreiashu commentedAttached an updated patch which makes sure that the rendered menu is the one in the current $node object when adding the active link.
Comment #6
andreiashu CreditAttribution: andreiashu commentedAttached a version against the latest stable 2.3 version
Comment #7
nateman332 CreditAttribution: nateman332 commented#4, #5 and #6 aren't working for stable version 2.3 for me; menu items are still not showing on secondary language.
Comment #8
nateman332 CreditAttribution: nateman332 commentedThis patch worked for me! All you do is delete this line of code in sites/all/modules/i18n/i18n_menu/i18n_menu.module:
Comment #9
pierrozone CreditAttribution: pierrozone commentedPatch #6 Displays menu block for default language but doesn't show child items and doesn't also show menu block in other languages
Comment #10
nateman332 CreditAttribution: nateman332 commentedComment #11
constantinejohny CreditAttribution: constantinejohny commented#8 Worked for me for translated content, paren and child items. Thanks!
Comment #12
JohnAlbinNeeds work then.
Comment #13
muschpusch CreditAttribution: muschpusch commentedSorry this isn't really related to menu_block but if people look for a workaround for rendering a second level menu (language aware)
Let's say your menu looks like this:
Main Item (english)
-- sub item (english)
-- sub item (english)
-- sub item (english)
Main Item (german)
-- sub item (german)
-- sub item (german)
-- sub item (german)
It will render
-- sub item (german)
-- sub item (german)
-- sub item (german)
OR
-- sub item (english)
-- sub item (english)
-- sub item (english)
Comment #14
jetcode CreditAttribution: jetcode commentedSeems like this bug hasn't been fixed yet. Here is my workaround (ugly but should works and that would be awesome if someone has an idea how to improve this!!!).
In a custom module, just implement hook_menu_block_tree_alter() and add this:
This way, all your menu blocks that display a menu starting from depth > 0 will be dynamic depending on the current language. Menu block with menu starting from root level (depth = 0) are not concerned.
Comment #15
Chandan Chaudhary CreditAttribution: Chandan Chaudhary commentedI was facing the same issue, as the translated menu items were not displaying on the respective language page.
The below code solves my problem
i have also attached the patch file as "menu_block_translation_fix.patch"
Comment #16
Chandan Chaudhary CreditAttribution: Chandan Chaudhary commentedComment #17
Lukey CreditAttribution: Lukey as a volunteer commentedI have been working on an issue where the menu_block cannot decide which language the active trail should be in.
For example, if I am on the english (default language) version of the page, the menu_block for this secondary level menu does not show up. dpm() of the $tree shows that the chinese menu items are getting active trail = TRUE when it should be the english translation of these menu items that is active. When it comes time to output the menu, only chinese items are in the menu tree, so nothing shows up at all and the block disappears since it is an english page.
The below seems to work to fix, although obviously recursing twice is nuts but I haven't had a chance to fix that problem yet. Basically $active_hack is storing the parent items so I can loop through again and set those to active_trail.
This solved the problem - any suggestions on edits to travel backwards from the active item so that I don't have to iterate once to find the active trail, and again to edit each link to set to active trail?