Problem/Motivation

If you add a custom menu to a site and it includes a link to <front> then sub items under that link do not show when that front page is viewed.

See #942782: Custom menus never receive an active trail.

See example at http://southamonline.org.uk - the front page link has a sub-item which does not show (http://southamonline.org.uk/archive). The 'Southam Pictures' link has a sub-item too, but this one shows.

Steps to reproduce

  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
  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
  9. When you go to the homepage, the sub item will not be displayed.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

magpie5212’s picture

Just to clarify that the link is to <front>. Sorry, I forgot it would vanish.

klonos’s picture

Title: Front page links do not show sub-items in the menu. » 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 ;)

xjm’s picture

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.

klonos’s picture

Version: 7.12 » 8.x-dev

...setting this to D8 then.

magpie5212’s picture

Sorry, I don't have a D8 running so I can't help there. I just need a fix on 7.

klonos’s picture

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

Dan Silver’s picture

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.

tsphethean’s picture

Assigned: Unassigned » tsphethean

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

tsphethean’s picture

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?

brandonpost’s picture

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

August1914’s picture

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

Dan Silver’s picture

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').

Madis’s picture

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

xjm’s picture

Issue tags: +Novice

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.

BrockBoland’s picture

Assigned: tsphethean » BrockBoland

Working on a test.

BrockBoland’s picture

Assigned: BrockBoland » Unassigned
Status: Active » Needs work
FileSize
760 bytes

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!

BrockBoland’s picture

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.

oriol_e9g’s picture

Status: Needs work » Needs review

Testbot?

Status: Needs review » Needs work

The last submitted patch, 1468420-16.patch, failed testing.

xjm’s picture

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.

BrockBoland’s picture

Status: Needs work » Needs review
FileSize
80.24 KB
1.43 KB
875 bytes

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.

BrockBoland’s picture

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.

lucascaro’s picture

Status: Needs review » Needs work
+++ 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.

BrockBoland’s picture

Status: Needs work » Needs review
FileSize
1.1 KB
1.1 KB

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.

Status: Needs review » Needs work

The last submitted patch, 1468420-24.patch, failed testing.

BrockBoland’s picture

Status: Needs work » Needs review
FileSize
991 bytes

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

Status: Needs review » Needs work

The last submitted patch, 1468420-26.patch, failed testing.

xjm’s picture

Issue tags: -Needs tests, -Novice

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

BrockBoland’s picture

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.

jrchamp’s picture

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!

Redart’s picture

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.

BrockBoland’s picture

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!

jurgenhaas’s picture

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.

marthinal’s picture

Status: Needs work » Needs review
FileSize
2.58 KB

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

marthinal’s picture

Issue summary: View changes

Codified the link.

Status: Needs review » Needs work

The last submitted patch, 34: d8-front-into-custom-link-1468420-34.patch, failed testing.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

thamas’s picture

Issue summary: View changes

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

thamas’s picture

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…

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

quietone’s picture

Version: 8.9.x-dev » 9.3.x-dev
Issue summary: View changes
Status: Needs work » Closed (cannot reproduce)
Issue tags: +Bug Smash Initiative
FileSize
3.93 KB

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!