Menu Block ignores active trail when "the menu selected by the page" is used

Technically speaking the node/NID/edit page isn't in the menu. Which is why the menu block isn't showing up.

But the current page is a tab which has a related default tab that _is_ in the menu. The correct fix would be to check if the current page is a tab and then looking for the default tab's path in the menu system.

The current patch hacks the ends of the path to find menu items. That approach is going to introduce bugs.

This would also fix the issue I'm having when using menu_position and the "menu selected by the current page" setting. The issue is the query returns no menu_name since there's no item in the menu_links table for a node using a menu_position rule so the menu block doesn't show. If it chose a menu name from the active trail this would be fixed

Can confirm the patch fixes my issue :)

+1 for this request. Ran into a situation just now:

We have a "Locations" content type. The main /locations page is a View with a map and a list, and that page is in our main menu. Clicking a location takes you to that node's page. But we're not putting all the individual Locations in the menu, because there's no easy automatic way to do it, and coding that isn't in the budget.

We are, however, using Menu Trail By Path to give active-trail to the /locations link itself. That should be sufficient to activate Menu Block visibility for a menu with <the menu selected by the page> set. But it's not.

Don't know if the patch works because we already added a separate menu block for those specific pages. But we'd love to see this implemented for the next time the need arises.

The menu position bug has already been fixed in #1524674: Use of $_GET['q'] ignores menu_position module.

The concrete example given in the issue summary should be fixed in the way I mentioned in #2.

We are, however, using Menu Trail By Path to give active-trail to the /locations link itself. That should be sufficient to activate Menu Block visibility for a menu with
set. But it's not.

That's the same bug as the menu position bug. Try menu_block 7.x-2.x-dev; it should fix your problem.

I didn't close the issue. I simply said “The concrete example given in the issue summary should be fixed in the way I mentioned in #2.” In fact, I just tried to reproduce this problem of the block collapsing when on the edit tab… and I couldn't reproduce. See #1935280: Menu block collapses when on any tab of a menu link besides "View"

So… show me an example where menu block isn't doing what you want and the patch form above fixes it.

I'm having this problem as well.

Even though I see a 'fix' describing the issue at #1524674: Use of $_GET['q'] ignores menu_position module has been committed and is present in 7.x-2.7 stable, I am still experiencing the problem.

I have a 'Primary Links' menu block that is set to use the menu selected by the page, because I have two menus at play on the website for this header area.

Most nodes and links on the site are natively added to the menu link list, and are visible at admin/structure/menu/manage/main-menu.

However, I'm using the menu_position module to show nodes of type 'Project' as a child of one of the links in this main-menu, so it looks like this:

Home
About
- Company
- Leadership
- - Bob
- - Mark
Projects
- All Projects 
- - [Individual project nodes (menu position rule)]
Contact	
- Connect
- Offices & Locations

So when I set the menu_block to use 'Main Menu' as the menu statically and I visit a node of type 'Project,' the Main Menu above appears in the header as expected and the proper menu items are lit up according to the active trail "Projects > All Projects > (This Project)".

However as soon as I switch the menu_block menu to '<the menu selected by the page>' and then revisit a node of type 'Project,' the Main Menu disappears -- the block is no longer in the HTML at all, as if menu_block is choosing no menu at all as its source.

This behavior occurs regardless of my menu_position settings. I've tried both:

• Insert the current page's title into the menu tree.
• Mark the rule's parent menu item as being "active".

Please help!

UPDATE:
I was using menu_position 7.x-1.1 with menu_block 7.x-2.7. I just updated menu_position to 7.x-1.2 and everything starting behaving as expected.

Voicing support for the functionality being provided by this patch.

Usage: Utilizing menu_trail_by_path to keep some items out of the menu structure, while still supporting bread crumbs and sidebar menu navigation of higher tier menus, but not showing active node in menu navigation.

Problem: menu_trail_by_path nodes aren't really in the menu (when selecting to not display them in the menu), so they don't trigger menu block navigation.
Other attempts: There are some other patches out there that will trigger the menu block, but rewrite the tree, and end up providing the wrong node value to the edit tabs

This patch: Allowed use of the menu_trail_by_path without modification, and provided all of the items need in the above usage.

This may not be the right place for the change, but it is a functional work around until a better solution is worked out.

We found this issue when we were attempting to assign menus by taxonomy term, using Menu Blocks that were set up to use "
" -- as noted in this thread the menus failed to appear under. The re-rolled patch #14 on 7.x.-2.x fixes the issue for us and it would be great to see this or a similar approach rolled into the module.

I have the same use case as described in #13 and patch #14 worked for me. Thank you.

Patch #14 works for me. Can someone reroll the patch?

Sorry for knocking this back. I'm a bit worried on 2 fronts with the current patch.

1. It introduces X breadcrumb item count queries without, what I'd expect would be short-cutting out once something is found.
2. $trail = menu_get_active_trail(); call is duplicated a few lines up, so another potential performance hit.
3. It's using href instead of link_path and I'm not sure why, which may be where some bugs show up.
4. db_query() could and probably does return false in a few instances

I read through the use-cases and really could use another good case for performance hit this will incur.