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.
Problem
After a clean install of the latest D8-x.dev, a standard install shows two menu links in the tools menu withe neither a title or a path. They do not appear on a minimal install. I do not know at this point where they are being added.
Comment | File | Size | Author |
---|---|---|---|
#4 | routes_in_tools_menu.png | 285.98 KB | Wim Leers |
#4 | routes_need_hook_menu-2078333-4.patch | 1.62 KB | Wim Leers |
#1 | tool-menu.jpg | 63.92 KB | dcrocks |
Comments
Comment #1
dcrocks CreditAttribution: dcrocks commentedIt looks like
Comment #2
dcrocks CreditAttribution: dcrocks commentedWent through a minimal install and enabled modules one at a time until the blank menu links showed up. It looks like they are being added by the 'contextual links' and 'edit' modules. Looked at a standard profile install and removed 'edit' and 'contextual links' and blank menu links disappeared.
Comment #3
dcrocks CreditAttribution: dcrocks commentedChanging this to one of the modules that generates the link; Haven't figured it out yet and I don't know when this changed.
Comment #4
Wim LeersGreat find! Thanks for reporting :)
It's these two routes that are both AJAX routes for under-the-hood use only:
contextual/render
edit/metadata
Your analysis really helped to get me on the way — thanks!
These two blank links are for the two above routes. They have corresponding
hook_menu()
entries because that's currently still necessary to ensureajax_base_page_theme()
is used.It's bizarre that they're the only ones that show up in the UI. There are plenty more there, including one more of
edit.module
:edit/form/%/%/%/%/%
. So why does this one show up and others don't?And just to be clear, by "others", I mean "a shitton others":
It seems the reason just two blank links appear and not a few dozen, is simply because they're the only two that don't contain a wildcard. That being said, the real problem AFAICT is that for an unknown reason, menu link content entities are being created for routes in the "tools" menu. I don't know why that is happening.
Attached is a patch that fixes the *symptom*, by setting the type of these routes to
MENU_CALLBACK
, like in the D5/6/7 days. But AFAIK all thathook_menu()
stuff is going away. Plus, that doesn't answer the question why *content entities* are being created automatically for *routes*, which are essentially code. It's likely there's a good reason, but I don't know it and I'd like to understand why this happens, and what the final solution will look like.Comment #5
dawehnerWell hook_menu() is currently there to fill up the menu tree, so if you have specified an item to be a MENU_NORMAL_ITEM, it will just appear.
Once we get pressure behind #1954892: Replace 'theme callback' and hook_custom_theme() with a clean theme negotiation system these hook_menu items could be removed.
Comment #6
webchickWow, good catch!
Committed and pushed to 8.x. Thanks!
Comment #7
Wim LeersHrm, yes,
MENU_NORMAL_ITEM
is applied by default to menu items that don't specify a type:As long as we don't ship with this very confusing approach, I'm fine :)
Thanks for the quick RTBC & commit!
Comment #8
dawehnerWell, this behavior existed since ever and is actually kind of nice DX, because you don't have to specify it in the 80% usecase.
Comment #9
Wim Leers#8: it definitely made sense in the pre-routes era. As an outsider to the whole WSCII/routing system stuff, it's difficult to assess to what degree the old stuff (
hook_menu()
in this case) is still being used. I was told I should not use it. Then it turned out I had to, just to set the theme callback. And now apparently it has this unexpected side effect. Do you see how it's easy to be misled? :)