Submenus of a parent menu item that links to the front page (<front>) do not show when viewing the site's front page.

...better issue title ;)

Thanks @magpie5212 for filing this.

Let's document a clear sequence of steps to reproduce this on 8.x if possible (starting from "Install Drupal 8.x using the standard profile.") We can use those to create an automated test demonstrating the bug.

...setting this to D8 then.

I'll try to test this and provide repro steps. I just need time.

I was able to reproduce this.

1. Install Drupal 8.x using the standard profile.
2. Create a page that we can link the menu sub item to. Go to node/add/page and create the node.
3. Go to structure->menus->add menu
4. I set the menu title to "custom_menu"
5. Add a link to the new menu with a path of <front>
6. Add another item to the custom menu with a parent link being the link created in step 5 and a path of node/1 (should be the node created in step 2)
7. Go to admin->structure->block
8. Move the custom menu to the header

When you go to the homepage, the sub item will not be displayed.

I have reproduced following the steps above. Trying to debug now.

Just a thought - if you set the top level menu item to be "show as expanded" (tick the option in the menu link add form) then the menu items display as expected - with the child items displayed.

Is this working as expected, or is this still a bug?

I reproduced the steps in #7. I agree with @tsphethean that it seems to work as expected by toggling the "Show as expanded" option on the top level menu item (the one that has the path <front>).

I also reproduced the steps in #7, and seems to work as expected.

Not sure if this is a bug, but with any other page, sub-menu items are shown by default (without having to check the 'show as expanded').

I would categorize this as a bug. The behaviour is different from normal menu links like Dan Silver mentioned, which I think shouldn't be the case? Setting the <front> page link to 'show as expanded' is not a good workaround for me since then the menu items directly below are always shown even if I'm on a unrelated page.

For the time being I have stopped using <front> as the path in menu links and manually set the front page path (same as in 'admin/config/system/site-information') in which case everything seems to work as expected (checking the differences here might be a good start in getting to the root of the problem). I have tested this on existing Drupal 7.x sites only though (maybe someone can check whether it's still the case on clean Drupal 7/8 installations).

Thanks everyone! Let's roll the STR from #7 into an automated test that fails when this bug is present.

Without researching too much, I'd hazard this has a similar cause to #942782: Custom menus never receive an active trail.

Working on a test.

Added a test to verify that the menu item is not visible on the front page.

This is my first-ever test, so please don't be shy in your feedback: I'd really like to know what I did wrong (or could have done better) so that my next one will be better!

Actually, this would be more appropriate as an addition to doMenuTests() than doCustomMenuTests(). The former applies to custom and standard menus, and I just confirmed that this bug is present in standard menus (such as Main Menu) as well.

Testbot?

Hmm, I'm a little concerned by this notice in the test failure on menu.test line 360:
Trying to get property of non-object

$title is set in verifyMenuLink() with $title = $parent_node->title;. From that method:

   // Verify parent menu link.
    if (isset($parent)) {
      // Verify menu link.                                                      
      $title = $parent['link_title'];
      $this->assertLink($title, 0, 'Parent menu link was displayed');

      // Verify menu link link.
      $this->clickLink($title);
      $title = $parent_node->title;
      $this->assertTitle(t("@title | Drupal", array('@title' => $title)), t('Parent menu link link target was correct'));
    }

$parent and $parent_node are both optional method arguments that default to NULL. And, of course the assertion fails looking for " | Drupal" with an undefined title. In the patch:

+++ b/core/modules/menu/menu.testundefined
@@ -94,6 +94,12 @@ class MenuTestCase extends DrupalWebTestCase {
+    $this->verifyMenuLink($item2, $node1, $item1);

So, it looks like this method expects the fourth argument if the third argument is specified, and (I think) the test is failing for the wrong reason. I'd suggest maybe moving the test as suggested in #17 and then examining the verbose results for the expected behavior. We might need to do our own check for the link rather than using the provided method.

Edit: I also made note of the oddity with these two optional parameters in #1326672-37: Clean up API docs for menu module.

Spent some time on this tonight, but still haven't figured it out.

I moved the code into the doMenuTests() function, as noted in comment #17, and tried implementing a custom check for the menu link as xjm suggested in #20, since verifyMenuLink() doesn't work when checking for $parent_node->title in the page title.

What I found is that this bug doesn't appear to manifest when running the tests; the test passes with this patch applied. When reviewing the verbose output from the drupalGet() call on line 266, the sub-item of the home menu item is visible (see attached screenshot). Any ideas?

I've also attached the interdiff to show what I changed from the patch in #16.

Oh, one other thing: this might also need to add the block to the sidebar, as addCustomMenu() does around lines 167-172. I tried adding this but couldn't get it to work. Without adding that, the Navigation menu block is added to the sidebar, but the block for the custom menu is not.

+++ b/core/modules/menu/menu.test
@@ -255,6 +255,20 @@ class MenuTestCase extends DrupalWebTestCase {
+    $front_item = $this->addMenuLink(0, '<front>', $menu_name);

You should add the last argument, expanded as FALSE here. otherwise it will set this menu item to expanded by default and will always show the sub menu link.

I can confirm that this patch fails when I add the last parameter as FALSE.

Thanks to lucascaro's assistance, the test is now failing when it should! I also added a check for the parent menu item, just to be on the safe side, and changed the assert message to make it clearer in the test result page.

If you're not careful, it's easy to attach the interdiff twice.

#26 looks like a correct test for this bug. Thanks @BrockBoland and @lucascaro!

I spent some time digging into this tonight, and I've managed to narrow down (but not identify) the problem.

menu_block_view() calls menu_tree(), which calls menu_tree_page_data(), which calls menu_link_get_preferred()…which is where the problem arises.

menu_link_get_preferred() should return the preferred menu item for the given path, but when the front page is requested ('node' in my case), it returns an empty value instead of an array.

Drilling down further, I found that the db_select query ($query) is not returning any values when on the homepage. I cast the object to a string to get the actual SQL, and worked it out to this:

SELECT ml.*, m.*, ml.weight AS link_weight
FROM 
menu_links ml
LEFT OUTER JOIN menu_router m ON m.path = ml.router_path
WHERE  (ml.link_path IN  ('node'))

Running this query in the DB results in a single result, but the execute() call isn't returning any data. This loop never runs:

foreach ($query->execute() as $candidate) {
  ...
}

That's as far as I've got. I can't figure out why that query isn't returning any results.

It looks like the top level link_path for 'node' is 'node/%'.

Also, I saw some people on the old issue are touting menu_get_menus() as a fix (to replace the menu_list_system_menus() call near line 2300 of includes/menu.inc). It might be worthwhile to do a quick evaluation with "if (function_exists('menu_get_menus')) { $active = variable_get('menu_default_active_menus', array_keys(menu_get_menus())); }" which is the same behavior as the other instances of that variable's initialization within the menu.module. If that resolves anything, it's likely that menu_set_active_menu_names() is being initialized with the system menus before the menu_default_active_menus variable is initialized to the full set of menus. It looks like the book.module calls menu_set_active_menu_names() directly, which might be a way to ensure that the static $active variable can be correctly populated.

Hope that helps!

Why issue for 8.x-dev ???

I use D7.14 and superfish menu (Navbar)
When I go to the homepage, the sub items are not displayed.

Does any one have an idea on how to fix this for 7.14 ?

Thanks.

It's an issue for 8.x because all bugs need to be fixed in the latest development branch and back-ported. As noted in the previous comments, it's a complex issue without a clear solution. If you want to try fixing it, we'd be happy to review your patch!

I ran into the same problem and need to add, that this wrong behavior happens for the path <front> and ALSO for the path user. At least, both menu items do not get the class "active-trail" like all other items do if they (or one of their children) are the currently displayed page.

I tried this like a possible first aproach I did some test and it seems to work adding front like the path...

Codified the link.

Just want to confirm that it is still an issue. (8.1.0)

Big news here! :)

I'm not sure what did I do, but the front menu item's sub-item just appeared! It's a D8.1.0 site which recently I added Pathauto and Menu Trail By Path modules to. I'll check if it works really with another clean install…

I tested this on Drupal 9.3.x, standard install, and was not able to reproduce the problem. I used the steps to reproduce from #7 (now in the IS) and when returning to the home page the sub-menu item was displayed. Here is the menu when I returned to the homepage.

Therefore, closing as cannot reproduce. If you are experiencing this problem reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core").

Thanks!