Menu hierarchy plugin should prefer top links over other matching menu links [#2527570]

If you have two menu links going to the same page, menu hierarchy should use the minimum-depth one to get the parent menu link.
That's what it does for menu links having parents, but if a menu link has no parent (top-level), it's not taken into account.
Here's a patch to fix this.

Comment	File	Size	Author
#2	crumbs-7.x-2.x-2527570-menu-toplevel.patch	2.2 KB	donquixote
#2
	menu-hierarchy-prefer-top-links.patch	1.43 KB	GaëlG

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

donquixote CreditAttribution: donquixote as a volunteer commented 26 July 2015 at 13:39

Hi,
I am not completely sure and convinced that the solution correctly covers all use cases.

Some cases to consider:

If more than one menu contain the (child) item, then the results will be ordered based on the priority list, not based on the order of candidates returned by the plugin.
There can be menus that represent a sub-section of the site, and the frontpage is not the correct "root item" for these menus.

One possible solution here could be to have a separate plugin for toplevel items, which can be separately prioritized.
Yes, this does add complexity, so maybe we should do this in 7.x-3.x, where the prioritization UI looks cleaner.

Comment #2

donquixote CreditAttribution: donquixote as a volunteer commented 26 July 2015 at 14:27

File	Size
crumbs-7.x-2.x-2527570-menu-toplevel.patch	2.2 KB

What about this?

It returns NULL for those menus where the child is a toplevel item.
It uses "LEFT JOIN" so we don't need the separate query.

Comment #3

donquixote CreditAttribution: donquixote as a volunteer commented 26 July 2015 at 14:32

This means:
- If a path appears more than once in a menu, and one of these is a toplevel item, then no parent candidate is returned for this menu, and other plugins can do their thing.
- If a path is a toplevel item in menu A, but a deeper item in menu B, then the parent from menu B will be used.
- If a path is a deeper item in menus A and B, and A is first in the priority list, then the parent from menu A will be used.

There can be menus that represent a sub-section of the site, and the frontpage is not the correct "root item" for these menus.

Maybe we could have a page where you can configure a "root item" for each menu (which would default to the frontpage).
Or we could assume that the toplevel item with smallest weight in each menu is the root item?

Comment #4

3 August 2015 at 01:42

donquixote committed fb599bb on 7.x-2.x

Issue #2527570 by donquixote, GaëlG: Menu hierarchy plugin should prefer...

Comment #5

donquixote CreditAttribution: donquixote as a volunteer commented 3 August 2015 at 01:52

Status:

Needs review

» Fixed

The commit fb599bb implements the behavior outlined in #3.
This means we do *not* imply that the frontpage is the correct parent for each toplevel item. Instead we give other plugins a chance.

Maybe we could have a page where you can configure a "root item" for each menu (which would default to the frontpage).
Or we could assume that the toplevel item with smallest weight in each menu is the root item?

This would have to be a follow-up.

Also notice the commit before this, 308a725, which changes the implementation of Special menu items with <nolink>, and removes the separate plugin.