Class active-trail not added to li element when linking to front page

I had the same problem. When change the menu linking for "Home" link from node/6 to the li lost it's active-trail that was used for styling. After applied the patch everything worked as it should.

Might not be the best solution to special case but I don't know if there is any other way.

I think is why using

menu_set_active_trail('my-menu','<front>')

Fail and make the menu block disappear.

I don't understand the tests than fail but we need to add some test for this patch anyway.

I have this problem and am wondering if the proposed patch is really a fix or does it fail in other places. If someone is watching this is this fixed or not?

TIA

Still have this issue in drupal 7.16

I'm also not getting children of in the secondary menu - maybe this is related. Sort of shocked here. Fighting this and the fact that "active" never shows up for "my account".

Workaround for the <front> links
http://drupal.org/node/1571058#comment-6788662

Patch in #8 works great, thanks @ttiurani!

As far I can tell, this would exist in Drupal 8 too? Also, #10 indicates there are problems with the patch...

See also possible related issue or duplicate: #1063278: Menu item linked to <front> doesn't know its active

I applied the patch v4 to 7.19, but it does't work

I'm using Nice menu. I can't combine Nice menu with Menu Block :(

Add this http://drupal.org/node/1571058#comment-6788662
Its works!

Alright, this takes the approach from the comment mentioned above and adds the active class attribute in the theme function - getting around the caching issues caused by the previous approach.

Attached patches for D8, and D7.

patch #20 works great!

Patch core at your own risk. Until core is updated appropriately, I like this solution better: http://drupal.org/node/1571058#comment-6788662

update to 7.22 and apply #20 - cool!

fix_missing_active_trail.patch queued for re-testing.

#20: core-fix_missing_active_trail-1578832-20.patch queued for re-testing.

As per #2126319: <strong>Strip HTML tags for issue titles in listings</strong>, HTML tags in issue titles are not entirely escaped on the listing page, which is breaking validity.

(and has been preventing http://drupalreleasedate.com from being able to parse the page in order to get a count of issues for some time now)

Patch in #20 still applies cleanly to 7.32

adding tag back.

Patch in #20 still applies cleanly to 7.39

This work-around almost works with Drupal 8.1.8...

1. Disable the default/standard 'Home' menu link on the 'Main navigation' menu:
   /admin/structure/menu/link/standard.front_page/edit
   
   
2. Add a new menu link to the 'Main navigation' menu:
   /admin/structure/menu/manage/main/add?destination=/admin/structure/menu/manage/main
   
   Menu link title: Home
   Link: /node

But /node is shown when you hover over the Home link, and /node will be exposed to search engines... neither of these are desirable.

I believe this is another symptom of the <front> or /node or / mess.

Harrumph, any chance of a fix getting into 8.x soon, or a functional patch for D8? :( :(

(Yes I know I'm not helping....... I'll look now and see if I feel capable enough to do something to help instead of just whining........)

Errrrr never mind! Apparently it "just works," we just had a config wrong (someone added the menu link via menu admin UI, and linked to the front page or node/1 -- as soon as I removed that link and instead edited node #1 and added the menu link from in there, it worked fine/no troubles).

Sorry and never mind and thanks!

Using superfish module has resolved it for me

I tried fixing this in the part that builds the menu tree, but time constraints on my project force me to take the template_preprocess_menu() route.

Shouldn't have changed the version. Sorry

Previous patch caused fatal errors with external urls,

Patch in #34 still applies cleanly to Drupal 7.59.

I can confirm that code from #46 works well. I use it as my theme preprocess until it will be tested and committed to core.

Tried patch #48 as described in #50

When I visit the frontpage. Not only the frontpage link < li > is in the active-trail. But also all siblings.

<ul class="nav navbar-nav">
  <li class="nav-item active">
    <a href="/" class="nav-link active is-active" data-drupal-link-system-path="<front>">Home</a>
  </li>
  <li class="nav-item active">
    <a href="/2" class="nav-link active" data-drupal-link-system-path="node/4">link2</a>
  </li>
  <li class="nav-item active">
    <a href="/3" class="nav-link active" data-drupal-link-system-path="node/5">link3</a>
  </li>
  <li class="nav-item active">
    <a href="/4" class="nav-link active" data-drupal-link-system-path="node/6">link 4</a>
  </li>
</ul>

Improved patch 46:

• Use PathMatcher->isFrontPage() to check if preprocess is needed.
• Add extra instanceof Url checks to make sure no WSOD occur.
• Check if the menu item Url object isRouted instead of isExternal, as only isExternal could still throw an exception if an invalid internal route is in the menu items.

This version is working for me.

Sorry lukassykora but your patch is just a less defensive version of my patch and it failed the tests, so changing it back to review on my patch.

The patch in 52 seems to make *all* links on the front page have the "active-trail" class instead of just links to the front page :(

i found a work-around for this issue, just create a disabled menu item for the true home page (e.g. /node/1) under home link.

The patch in #52 applied cleanly on 8.7.8 and it worked for me. I cannot confirm the side effect mentioned in #57 - every menu link looks like it has the appropriate classes and only links representing the current page show as is-active.

Added an automated test for 8.8 and 8.9 to the patch #52.

Hopefully this can be committed soon.

I think #60 is missing a patch. This issue needs an automated test in order to be committed.

@Martijn de Wit, can you please dig up the automated test that you wrote and somehow failed to upload to this issue?

patch #52 still works great! Just tested it manually.

@Martijn de Wit, could you please find that automated test you wrote 5 months ago and somehow failed to upload?

Had to reroll patch 52 for Drupal 9.0.x

So to simplify I up uploading two patches, one for 9.0.x and the other for 8.9.x/8.8.x/8.7.x

patch 8 is for D7, still applies cleanly, I'll split that into a new seperate D7 issue

For the D7 issue:
#3119861: [D7] Class active-trail not added to li element when linking to front page

Active class missing (illustration)

Active After Applying Active Class

no, sry

after a few weeks of testing, patch 64 has regressions, it caused more than one link to have the active trail classes on the same page

I backed off the patch and removed it from our build.

As a workaround , our links for both of our languages are on one menu, internal links are fine, for external links we're using a workaround with css using a contrib module which allows specifying a class to the link. There's other ways to work around the external links I've used this method and another is to use also html lang attribute then the a element css selector on the href attribute based on a pattern to hide or show the opposite language external link.

Using one menu for both languages our active trail works fine. I'm not sure about the site default page issue haven't noticed it yet.

Anyhow, the patch 64 was derived from the others and I backed it off, no longer using it, doing a workaround instead.

previously we had menus for the default language and another different menu with another language and used block visibility on language for this, but this method proved to break the active trail for the 'other' language. So workaround is to use one menu for both our languages as I mentioned in this comment.

hope this helps.

We should fix this bug in D8 too, so filing against 8.8.x (which is the current bugfix support branch). The issue will be automatically updated to 8.9.x after the last 8.8.x bugfix release. Thanks for juggling all the different patches for this fix!

Just applied patch 64 before reading comment 69... Can confirm 64 adds the in_active_trail too generously 😉

Ahh so the problem for me is that the frontpage is a node (node/1). So:

$validHomepageRoutes = ['', $homepageUrl->getRouteName()];

This contains and "entity.node.canonical" so every menu item that is front or a node gets flagged.

This being not fixed leaves us wanting to fix this.

challenges:

• keep active trail functionality working for all links even if they are in another language
• ensure wcag keyboard navigation is not broken by our workaround, which we wouldn't have to do if this issue was fixed.
• wcag keyboard navigation fix is required because hidden links in a menu are not tabbable and since we display:none the other language link using an eng-only and fra-only / esp-only / jap-only class that goes something like html['lang='fr'] .eng-only { display:none; }
• this breaks wcag , so go further into javascript now, and remove the .eng-only elements something like $(html['lang='fr']).find('.eng-only').remove(); using jQuery (actual code we're using is not exactly this but just for an idea).
• By removing the display:none element from the html dom, the keyboard tab works and keyboard menu navigation works hence we can conserve our wcag compliance and accessibility

rather than do these workarounds, we would like to add a menu block per language allowing us to have unique weights for menu links and not have to fuss about external link translation for the url which is not always the same , often each language has an external link equivalient but for whatever reason (maybe explained above) this breaks the active-trail likely due to the bug mentionned above.

Currently we're working around this issue by using the https://www.drupal.org/project/menu_link_attributes menu_link_attributes module to provide a class attribute for links. We put this together on the same menu for both languages instead of a menu for each language (weights is another issue)

We want to make sure to maintain active trail functionality in both languages, there's the active class that indicates that the current link is what we're presently on, this is part of the menu functionality we didn't want to break and also keyboard navigation, due to wanting active trail to work in both languages we used one menu for two languages instead of two menus due to us wanting to work with what works for active trail menu links, one menu, links of all languages, internal links are no problem as they have a label that is translated and the internal link is automatically generated however external links like this one required a change in implementation to both the javascript and css, so we put a eng-only class on the english link that puts display: none on for the english link in french and a fra-only class on the french external link and there's another class attribute also, Drupal will render both links , css hides the other language external link, HOWEVER this does not fully allow wcag compliance in my recent wcag audits, SO we wrote some javascript to remove the other language link after the page is ready before the user navigates with the keyboard so when the menu link is configured as such using the specified class the javascript will also kick in and actually remove the other language link from the front end display which allows keyboard navigation to function correctly (wcag compliance, keyboard navigation is required). So the page renders, the css hides the other language link so it is never visible, then the javascript kicks in and removes the other language link from the html and thus we are able to pass wcag keyboard navigation and use the keyboard and tab key as expected.

it could be easier!

I'm going to try and address this in MenuTreeStorage::loadByRoute. Reasoning for this:

Assume you have the front page set as /node/1234. Also assume you have a menu named main and that menu has a single link which uses <front>.

Given the above, currently if you were to attempt to invoke MenuTreeStorage::loadByRoute('entity.node.canonical', ['node' => 1234], 'main'), you would get no results, even though that node is the front page.

I think the best course of action here is for the service to be aware of whether or not the passed route name/parameters represents the front page, and if it does then make the 'route_name' portion of the query part of an OR condition, where that condition also checks for <front>.

EDIT: I realize I didn't explain why this actually solves this issue. Which menu items get flagged as active comes from Drupal's menu.active_trail service. That service uses the current page's route match to get the page's route name and parameters, and invokes the aforementioned function to get the active link, and then it gets that links parents to build the rest of the trail.

The current page's route match will never, ever be the <front> route, it will always be what the actual route object is for that page in the system. So, we have to help MenuTreeStorage understand what the front page is.

Opened a MR with a somewhat rough implementation of where I think this needs to go. My local testing has been positive so far, and it appears to fix this issue in its entirety. I am not sure what kind of performance hit this adds. Still needs automated tests.

Yeah don't use the above branch for anything yet, lots of failed tests relating to cyclic dependencies, I'm hoping to be able to dig into it later today.

This is the circular reference error thrown that is mentioned by @Ipeabody:

Circular reference detected for service "plugin.manager.menu.link", path: "plugin.manager.menu.link -> router.no_access_checks -> route_enhancer.param_conversion -> paramconverter_manager -> drupal.proxy_original_service.paramconverter.menu_link".

I've previously also noticed some weird behavior in the active trail when the homepage contained a query string (example.org?foo=bar). Weirdest that I fgured out is that there is also JavaScript involved. If you disable Javascript the front page never gets an active trail class.

Linking as relevant issues.