Blank links in tool menus because routes are automatically added to the Tools menu

Great find! Thanks for reporting :)

It's these two routes that are both AJAX routes for under-the-hood use only:

1. contextual/render
2. 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 ensure ajax_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 that hook_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.

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 that hook_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.

Well 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.

Wow, good catch!

Committed and pushed to 8.x. Thanks!

Hrm, yes, MENU_NORMAL_ITEM is applied by default to menu items that don't specify a type:

    $item += array(
      'title' => '',
      'type' => MENU_NORMAL_ITEM,
      'module' => '',
      '_number_parts' => $number_parts,
      '_parts' => $parts,
      '_fit' => $fit,
    );

As long as we don't ship with this very confusing approach, I'm fine :)

Thanks for the quick RTBC & commit!

Well, this behavior existed since ever and is actually kind of nice DX, because you don't have to specify it in the 80% usecase.

#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? :)