Add a query tag to the query in menu_link_get_preferred() to allow modules to alter the query

Misread.

There's a tag translatable added many times in Drupal Core, but not used (there's no hook_query_translatable_alter()), that could be added.

Adding it in menu_link_get_preferred() query would allow i18n_menu to alter it and then filter by language the results.

See #881322: Multilevel menu fails to create active menu trail with same link_path in different languages for the upcoming patch to i18n_menu.

Apparently, using translatable tag, since it's being used in _menu_build_tree() is creating issues when administrating translations with the patch I posted in the i18n_menu issue.

I simply fixed it, since this tag is NEVER user in the Drupal Core, by deleting its addition in _menu_build_tree().

Applying the joined patch will make the patch I posted in this issue work without any failure.

Wrong fix, you should instead use a different, new tag for the query. translatable has a specific purpose (that is not really used anywhere, but that's a different topic, just removing it is not an option as someone out there might rely on it).

Als updated the title and this will need to be added to 8.x first and then backported.

I agree that using an existing tag could cause some issues to users who might be using it.

So I created translatable_preferred_menu_links tag, and I added it to menu_link_get_preferred().

Here's the patch.

I'm posting a patch related to this one in the i18n menu issue.

This patch, combined with the one mentioned in the i18n menu issue works when you have a single menu in which you put menu items for each language.

As mentioned above, this needs to go into Drupal 8 before it can be considered for backport.

Also, the code comment needs some editing for grammar (or maybe remove the comment altogether? - not sure if it's actually necessary).

I have the same problem as in the issue description. I can confirm that #6 works for D7.

fix link

A solution with a query tag would be great, but this tag should not translation specific as in the patch #6 ("translatable_preferred_menu_links"). More like "preferred_menu_links" in case we have to alter the preferred menu link in other situations, when multiple menu links use the same link path.

Or would it a better solution when this manipulation is possible over a hook like "hook_menu_link_get_preferred_menu_link($menu_links)" after the query?

I, too, needed a way to alter the query in menu_link_get_preferred(), and adding a tag was the perfect way to do it.

In my (client's) case, they were adding the same node twice into the same menu, and the second menu item was always activated when they wanted the first one to be.

I suspect that this is because, lacking any order by clause on the query in that function, rows were returned in the order created and the newest one (i.e. the one with the highest mlid) became the preferred candidate for the given path.

With the tag added, I am able to do a simple:

/**
 * Implements hook_query_TAG_alter().
 */
function example_query_preferred_menu_links_alter(QueryAlterableInterface $query) {
  $query->orderBy('mlid', 'DESC');
}

weri's suggestion to use a more generic tag made sense to me, so that's the one I used.

Lastly, I switched this back to Drupal 7 because the query in menu_link_get_preferred() has been replaced with a call to entity_load_multiple_by_properties() (I guess menu links are entities in D8?) and I have no idea how to alter that result set.

I reviewed and tested the patch #11. It works as expected and I think it's RTBC.

Patch #11 is good.

11: menu.inc-preferred_menu_links_tag-1854134-11.patch queued for re-testing.

Guess this goes back to RTBC if the test failure was a fluke.

11: menu.inc-preferred_menu_links_tag-1854134-11.patch queued for re-testing.

11: menu.inc-preferred_menu_links_tag-1854134-11.patch queued for re-testing.

There we go. Patch passed testing now.

I'd really love to see this get committed. I'm trying to solve the same issue as jeffam in #11. In fact, I was trying to write a module that would let users specify which of several redundant menu links would act as the "canonical" one. In digging through the code to figure out how Drupal decided which is the preferred menu link, I came to this query and noticed there's currently no way to hook into it, or alter the menu_link_get_preferred output in any way.

Back to RTBC assuming that was a testbot fluke.

Committed to 7.x - thanks!

(And yeah, I think there is no aspect of this patch that is relevant for Drupal 8 anymore.)