Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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
- Install Drupal 8.x using the standard profile.
- Create a page that we can link the menu sub item to. Go to node/add/page and create the node.
- Go to structure->menus->add menu
- I set the menu title to "custom_menu"
- Add a link to the new menu with a path of
- 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)
- Go to admin->structure->block
- Move the custom menu to the header
- 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
Comment | File | Size | Author |
---|---|---|---|
#47 | Screenshot_2021-06-27 test 2 dev1-web.png | 3.93 KB | quietone |
#34 | d8-front-into-custom-link-1468420-34.patch | 2.58 KB | marthinal |
#26 | 1468420-26.patch | 991 bytes | BrockBoland |
#24 | 1468420-21to24.interdiff.txt | 1.1 KB | BrockBoland |
#24 | 1468420-24.patch | 1.1 KB | BrockBoland |
Comments
Comment #1
magpie5212 CreditAttribution: magpie5212 commentedJust to clarify that the link is to
<front>
. Sorry, I forgot it would vanish.Comment #2
klonos...better issue title ;)
Comment #3
xjmThanks @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.
Comment #4
klonos...setting this to D8 then.
Comment #5
magpie5212 CreditAttribution: magpie5212 commentedSorry, I don't have a D8 running so I can't help there. I just need a fix on 7.
Comment #6
klonosI'll try to test this and provide repro steps. I just need time.
Comment #7
Dan Silver CreditAttribution: Dan Silver commentedI was able to reproduce this.
<front>
When you go to the homepage, the sub item will not be displayed.
Comment #8
tsphethean CreditAttribution: tsphethean commentedI have reproduced following the steps above. Trying to debug now.
Comment #9
tsphethean CreditAttribution: tsphethean commentedJust 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?
Comment #10
brandonpost CreditAttribution: brandonpost commentedI 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>
).Comment #11
August1914 CreditAttribution: August1914 commentedI also reproduced the steps in #7, and seems to work as expected.
Comment #12
Dan Silver CreditAttribution: Dan Silver commentedNot 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').
Comment #13
Madis CreditAttribution: Madis commentedI 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).Comment #14
xjmThanks 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.
Comment #15
BrockBoland CreditAttribution: BrockBoland commentedWorking on a test.
Comment #16
BrockBoland CreditAttribution: BrockBoland commentedAdded 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!
Comment #17
BrockBoland CreditAttribution: BrockBoland commentedActually, this would be more appropriate as an addition to
doMenuTests()
thandoCustomMenuTests()
. 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.Comment #18
oriol_e9gTestbot?
Comment #20
xjmHmm, 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:$parent
and$parent_node
are both optional method arguments that default toNULL
. And, of course the assertion fails looking for " | Drupal" with an undefined title. In the patch: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.
Comment #21
BrockBoland CreditAttribution: BrockBoland commentedSpent 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, sinceverifyMenuLink()
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.
Comment #22
BrockBoland CreditAttribution: BrockBoland commentedOh, 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.Comment #23
lucascaro CreditAttribution: lucascaro commentedYou 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.
Comment #24
BrockBoland CreditAttribution: BrockBoland commentedThanks 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.
Comment #26
BrockBoland CreditAttribution: BrockBoland commentedIf you're not careful, it's easy to attach the interdiff twice.
Comment #28
xjm#26 looks like a correct test for this bug. Thanks @BrockBoland and @lucascaro!
Comment #29
BrockBoland CreditAttribution: BrockBoland commentedI spent some time digging into this tonight, and I've managed to narrow down (but not identify) the problem.
menu_block_view()
callsmenu_tree()
, which callsmenu_tree_page_data()
, which callsmenu_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:Running this query in the DB results in a single result, but the
execute()
call isn't returning any data. This loop never runs:That's as far as I've got. I can't figure out why that query isn't returning any results.
Comment #30
jrchamp CreditAttribution: jrchamp commentedIt 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!
Comment #31
Redart CreditAttribution: Redart commentedWhy 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.
Comment #32
BrockBoland CreditAttribution: BrockBoland commentedIt'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!
Comment #33
jurgenhaasI ran into the same problem and need to add, that this wrong behavior happens for the path
<front>
and ALSO for the pathuser
. 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.Comment #34
marthinal CreditAttribution: marthinal commentedI tried this like a possible first aproach I did some test and it seems to work adding front like the path...
Comment #34.0
marthinal CreditAttribution: marthinal commentedCodified the link.
Comment #38
thamasJust want to confirm that it is still an issue. (8.1.0)
Comment #39
thamasBig 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…
Comment #47
quietone CreditAttribution: quietone as a volunteer commentedI 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!