First of all, let me tell you that I deeply love this module!
Well written and so easy to use: great job!

I am experiencing what I think is a bug:
Menu Block seems to ignore active trail when "the menu selected by the page" is used, that is, it seems to only care about whether current menu item is in a menu to display a block, ignoring its ancestors in the active trail.
As a result, a "Current menu" block may completely disappear because current menu item is not inside it, even if its ancestors in the active trail are.

Here is a simple concrete example:
- create a simple hierarchy of menu links in Main menu, leaf being a link to a node.
- create 2 menu blocks: Main menu (level 1) and Current menu (expanded levels 2+)
- navigate to the leaf node: Current menu (expanded levels 2+) shows up as expected
- edit the leaf node: Current menu (expanded levels 2+) disappears :-(

This works as expected when "the menu selected by the page" is not used.

IMO, in such a case, Menu Block should rely on active trail to process a "Current menu".
This way, Menu Block would also support any special active trail customizations made by site developer.

I will try to work on a patch for this.

Files: 

Comments

Status:Active» Needs review
StatusFileSize
new1.76 KB

Attached patch works for me.
(I'm not really satisfied by my comments though...)

Status:Needs review» Needs work

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.

The current patch hacks the ends of the path to find menu items.

What do you mean by "hacks the ends of the path"?

The local task example was just a simple example. Menu Block should not only care about tabs but also about any customization made to active trail using for instance menu_set_active_trail().
That's what patch does. It doesn't stop when not finding a link to current path in a menu but checks the whole active trail from its tail to its head.
What kind of bug could this bring?

Status:Needs work» Needs review

Changing to "needs review" again to get feedback from users.

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.

Status:Needs review» Needs work

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.

After having a look at the committed fix, it is clear that it won't work in all cases, simply because it only takes into account the tail of the active trail, completely ignoring its ancestors.
Too bad my patch was not given any chance.

Status:Needs work» Postponed (maintainer needs more info)

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.

Status:Postponed (maintainer needs more info)» Active

Hi John Albin.
Here is a concrete example.
The demo site below uses the latest 7.x-2.x-dev version of Menu Block.

1. Go to http://d7.absyx.fr (DNS info might not be propagated yet, so come back later if site does not show up)
2. You will find a main menu item "My Page". Click on it
It displays 2 menu blocks. Both display expanded levels 2+ of the Main menu. But the first one uses "Current menu" while the 2nd one uses "Main menu".
3. Click on item "Articles tagged with Misc".
It will display page taxonomy/term/1, that is, a list of articles tagged with term #1 that I called Misc.

This demo site uses a custom module altering active trail to link nodes to a parent page, using core function menu_set_active_trail(). This means that the articles tagged with Misc will automatically be displayed as children of the Articles tagged with Misc page in the active trail.
4. Now click on an article.
Active trail shows: Home » A page » Articles tagged with Misc
Here is the bug: while Main menu (expanded levels 2+) is still here as expected, Current menu (expanded levels 2+) disappears.

Let me know when you have seen this and I will upload my fix.

Issue summary:View changes

Missing word