[regression] missing menu active trail since Drupal 9.5.9

We have two options here

\Drupal\Core\Menu\MenuActiveTrail::getActiveLink or \Drupal\Core\Menu\MenuTreeStorage::loadByRoute can filter out default params.

Which would likely require using \Drupal\Core\Routing\RouteProvider::getRouteByName to load the route to get the defaults.

Or alternatively \Drupal\Core\Menu\MenuTreeStorage::preSave could add in defaults prior to save

I'm thinking \Drupal\Core\Menu\MenuTreeStorage::loadByRoute is probably the best place to do it

Thoughts?

Changing title per Special titles.

Thanks a lot wells. The issue is also related to Menu block module because it also does not work if the Initial visibility level is set to higher than 1.

Patch works fine and solved my issue.

+++ b/core/lib/Drupal/Core/Menu/MenuTreeStorage.php
@@ -111,15 +119,18 @@ class MenuTreeStorage implements MenuTreeStorageInterface {
-  public function __construct(Connection $connection, CacheBackendInterface $menu_cache_backend, CacheTagsInvalidatorInterface $cache_tags_invalidator, $table, array $options = []) {
+  public function __construct(Connection $connection, CacheBackendInterface $menu_cache_backend, CacheTagsInvalidatorInterface $cache_tags_invalidator, RouteProviderInterface $route_provider, $table, array $options = []) {
     $this->connection = $connection;
     $this->menuCacheBackend = $menu_cache_backend;
     $this->cacheTagsInvalidator = $cache_tags_invalidator;
+    $this->routeProvider = $route_provider;

We will need a BC dance here, to check if the fourth argument is a string etc, someone could be sub-classing this

I'll work on this and the fails later in the week

Any chance you're using taxonomy_menu here?

The fails indicate this breaks functionality for menu links created via the core UI, but the fix is needed (in my testing) for taxonomy_menu

I think the issue exists there, as it is hard-coding the route params to taxonomy_term only, which if you have views enabled breaks routing for views

Edit, it looks like #3358402-9: [regression] route defaults are now automatically route parameters has steps to test this with just core, I'll make a core test for that

Unfortunately, at this stage, understanding many elements of this bug are beyond my capabilities, but I can confirm #3277784 caused a number of sections, on a site I manage, fail to render after upgrading to 9.5.9. Issue summary above seems to align with the problem I've encountered. Applying the reversion patch in #2 fixes all issues and I'll be using that so I can take the site to 9.5.9 for now.

Using patch #5 the missing sections of the site are rendering again, but the patch creates new problems with the site breadcrumbs. The site has both current_page_crumb and menu_breadcrumb installed and with patch #5 applied (no issues with #2 reversion applied) I'm getting duplication on the last breadcrumb entry and only on term pages. Sorry, I have not been able to isolate why.

Given upgrading from 9.5.8 (or prior) to 9.5.9 can result in parts of a page no longer rendering (causing a blocker to upgrade for some) is Normal Priority flag sufficient for this issue?

@wells, I wrote a test for this using your steps to reproduce, but it consistently passes.

So I tried the steps manually, and I can't reproduce, here's an example from Umami showing the menu link as active.

I'm using taxonomy menu and the issue comes from when you use that with views to generate the taxonomy page.

This approach should work for both taxonomy_menu and the expected behaviour in core for views.

I don't think it would be acceptable to put this into core until we can get steps to reproduce with just core.

Here's the patch to go with the interdiff above

1. +++ b/core/lib/Drupal/Core/Menu/MenuTreeStorage.php
   @@ -655,17 +674,35 @@ public function loadByProperties(array $properties) {
   -    $query->condition('route_param_key', $param_key);
   +    $or = $query->orConditionGroup();
   +    $or->condition('route_param_key', [$param_key, $param_key_without_defaults], 'IN');
   +    $query->condition($or);
   

   ah I started out with an OR and ended up with an IN, this can be simplified

2. +++ b/core/lib/Drupal/Core/Menu/MenuTreeStorage.php
   @@ -673,6 +710,7 @@ public function loadByRoute($route_name, array $route_parameters = [], $menu_nam
   +    $query->orderBy('route_param_key');
   

   In case there are multiple matches, go with the shortest one

3. +++ b/core/modules/system/tests/src/Functional/Menu/BreadcrumbTest.php
   @@ -218,6 +239,14 @@ public function testBreadCrumbs() {
   +    $edit = [
   +      'title[0][value]' => 'Sub views menu',
   +      'link[0][uri]' => '/test-menu-link',
   +      'menu_parent' => "$menu:{$link->getPluginId()}",
   +    ];
   +    $this->drupalGet("admin/structure/menu/manage/{$menu}/add");
   +    $this->submitForm($edit, 'Save');
   

   This is the test case @wells mentioned in the other issue, this test passes and so does my manual testing

@wells 11.x is a bit like 'main' or 'master' in other branches. We've added it for now instead of a 'main' branch because there's a few things on d.o that don't support 'main' and expect versions to be named a certain way. We will eventually move to 'main' when those things are resolved.

We've made this change so that people don't have to constantly change the target of merge requests.

In terms of where you should be testing, the issue that caused the regression here went into all branches so I'd expect it exists in all three branches.

I was testing with 11.x, but I can repeat my testing on 9.5 in case it is unique to that version

Hope that helps

I tested this in 9.5 and still could not replicate what you were seeing:

* Install Umami
* Add a new view, with a menu link
* Browse to that page, see the active menu trail on that link

The fail is odd

Expected breadcrumb Home on http://php-apache-jenkins-drupal-patches-185585/subdirectory/test-menu-link but found Home

🤔

The test passes locally, so I'll need to dig into it a bit, could be down to things running in a subdir on the testbot

phpunit -c app/core/ app/core/modules/system/tests/src/Functional/Menu/BreadcrumbTest.php --filter=testBreadcrumbs
⏳️ Bootstrapped tests in 0 seconds.
🐘 PHP Version 8.1.16.
💧 Drupal Version 11.0-dev.
🗄️  Database engine mysql.
PHPUnit 9.6.8 by Sebastian Bergmann and contributors.

Testing Drupal\Tests\system\Functional\Menu\BreadcrumbTest
.                                                                   1 / 1 (100%)

Time: 00:26.320, Memory: 10.00 MB

OK (1 test, 145 assertions)

Ah so I was looking at the styling, which both had the underline, I wasn't looking for the class.

I can take it from here - thanks

trying to fix the test first

These should be red/green

Fixed coding standards issues

Hiding old patches

Also was able to verify on Umami install.

Patch #30 resolves the issue for me.

Hello, I think I'm facing a problem of this issue. But the patch of #30 not work for me.
So I tried to read records of menu_tree.

Data in 9.5.8 is below:

MySQL [drupal]> SELECT menu_name, route_name, route_param_key FROM menu_tree WHERE menu_name = 'breadcrumbs' LIMIT 6;
+-------------+--------------------------------+-------------------+
| menu_name   | route_name                     | route_param_key   |
+-------------+--------------------------------+-------------------+
| breadcrumbs | view.news_and_topics.page_2    | arg_0             |
| breadcrumbs | entity.taxonomy_term.canonical | taxonomy_term=145 |
| breadcrumbs | entity.taxonomy_term.canonical | taxonomy_term=143 |
| breadcrumbs | entity.taxonomy_term.canonical | taxonomy_term=149 |
| breadcrumbs | entity.taxonomy_term.canonical | taxonomy_term=147 |
| breadcrumbs | view.news_and_topics.page_2    | arg_0             |
+-------------+--------------------------------+-------------------+

Data in 9.5.9 with patch #30, after drush cache:rebuild is below:

MySQL [drupal]> SELECT menu_name, route_name, route_param_key FROM menu_tree WHERE menu_name = 'breadcrumbs' LIMIT 6;
+-------------+--------------------------------+-----------------------------------------------------------+
| menu_name   | route_name                     | route_param_key                                           |
+-------------+--------------------------------+-----------------------------------------------------------+
| breadcrumbs | view.news_and_topics.page_2    | arg_0&view_id=news_and_topics&display_id=page_2           |
| breadcrumbs | entity.taxonomy_term.canonical | taxonomy_term=145&display_id=page_1&view_id=taxonomy_term |
| breadcrumbs | entity.taxonomy_term.canonical | taxonomy_term=143&display_id=page_1&view_id=taxonomy_term |
| breadcrumbs | entity.taxonomy_term.canonical | taxonomy_term=149&display_id=page_1&view_id=taxonomy_term |
| breadcrumbs | entity.taxonomy_term.canonical | taxonomy_term=147&display_id=page_1&view_id=taxonomy_term |
| breadcrumbs | view.news_and_topics.page_2    | arg_0&view_id=news_and_topics&display_id=page_2           |
+-------------+--------------------------------+-----------------------------------------------------------+
6 rows in set (0.001 sec)

I'm using this "breadcrumbs" menu with menu_breadcrumb module and breacrumbs of my site by the module are currently broken, because SQL like `WHERE route_param_key = 'taxnomy_term_145'` in the module not working properly by this problem.

I think this expanding `route_param_key` is from #3277784 and it may be fixed #2 patch, but I did not try yet.
I'm afraid of applying #2 patch causing any other problems or conflict with internal data structure of future version of Drupal.

Could anybody give me some advice?

because SQL like `WHERE route_param_key = 'taxnomy_term_145'` in the module

I'm sorry. The sql is executed in MenuTreeStorage::loadByRoute() called by menu_breadcrumbs through MenuLinkManager::loadLinksByRoute().

Needed to update new code in workspaces that sub-classes the menu tree storage service

Verified on Umami again and still seeing the fix.

Ran into this today with some view pages. I'm running Drupal 10.1 so 10.x is affected by this as well. Patch #38 wouldn't apply to 10.1 for me, but #30 did apply and fixed the issue.

In my case, finally I got this workaround.
Note that this includes a menu name for menu_breadcrumbs in my site, so you can not use this directly.

--- core/lib/Drupal/Core/Menu/MenuTreeStorage.php.orig	2023-07-13 16:19:51.661163432 +0900
+++ core/lib/Drupal/Core/Menu/MenuTreeStorage.php	2023-07-13 16:21:07.000000000 +0900
@@ -665,7 +665,17 @@
     $query = $this->connection->select($this->table, NULL, $this->options);
     $query->fields($this->table, $this->definitionFields());
     $query->condition('route_name', $route_name);
+    if ($route_name == 'entity.taxonomy_term.canonical' && $menu_name == 'MENU_FOR_menu_breadcrumbs') {
+      $q_group = $query->orConditionGroup()
+        ->condition('route_param_key', $param_key)
+        ->condition('route_param_key', "{$param_key}\\&%", 'LIKE');
+
+      $query->condition($q_group);
+    } else {
     $query->condition('route_param_key', $param_key);
+    }
     if ($menu_name) {
       $query->condition('menu_name', $menu_name);
     }

I was also hit by this as follows. I'm adding this comment here so that this kind of use case can be taken into account and as a courtesy to other community members who might have similar use case. I'm on 10.1 so I did not test patch #38 because as per #40, it won't apply to 10.1. I volunteer to test a new patch against 10.1 if there will be a patch that applies to 10.1

Context and use case
I have a custom module which creates competition menu links dynamically with plugin derivatives. "Competition" is a node content type specific to my site but the point here is that I'm dynamically adding competitions of the ongoing season to the menu.

My class Plugin/Menu/CompetitionMenuLink extends MenuLinkDefault and then the derivative class Plugin/Derivative/CompetitionMenuLink extends DeriverBase.

My symptom was as follows:

• I have a page view called "Finnish Championships", which is route view.competitions_current.page_1. I have this page view in my menu.
• My custom module is expected to generate the menu links as children of this page view
• The dynamically generated menu links were not generated as expected

Debugging observations

• I used menuLinkManager->loadLinksByRoute to search the parent menu link for the menu links to be created.
• I observed that menuLinkManager->loadLinksByRoute($route) did not return the parent menu link anymore like it did earlier.
• Based on the comments above, I checked menu_tree table in the database and observed that route parameters view_id and display_id had been added to route_param_key and route_params.
• Modifying the code so that I pass the route AND these route parameters to menuLinkManager->loadLinksByRoute resolved the issue for me.

Cheers,
Markus

+    // Also query without any default route parameters as they may not be
+    // present in the computed route_param_key.
+    $route_parameters_without_defaults = $route_parameters;
+    try {
+      $route = $this->routeProvider->getRouteByName($route_name);
+      foreach (array_keys($route_parameters_without_defaults) as $param) {
+        if ($route->hasDefault($param)) {
+          unset($route_parameters_without_defaults[$param]);
+        }
+      }
+    }

Shouldn't this be only removing route keys which MATCH the default? Otherwise, if you pass in a route key, which HAS a default, but is not the default, this will then match routes in the table which are for the default value, not the given value? Perhaps I'm misunderstanding the logic but it seems this might be only meant to be removing if the value is default, not if it has a default.

Expanding upon feedback from comment #40 above, I am experiencing this with Views pages that are listed as sub-menu items below top-level items in the main menu. In Twig menu--main.html.twig, menu.items[n].in_active_trail is not being activated for the parent menu item. Other sub-menu items that are not view pages do have the in_active_trail value set for the parent. I'm running Drupal 9.5.10 and the patch in #38 does not apply. On the other hand the patch in #30 does apply, but doesn't fix the issue. My workaround for now is to 1) convert the Views Page display to a Block display, 2) create a node with the desired path alias from the Page display, and 3) drop the View block onto the page — either via Layout Builder for the node or via Block regions in the theme with appropriate block visibility rule to restrict it to the desired path. Not an ideal solution, but it works.

Edit: I discovered that the reason the active trail was not getting added to the parent was because the sub-manu items appeared in the main menu multiple times but several copies were "disabled" and/or located under other disabled top-level menu parents. Once deleting the dupes and cleaning out the menu, the active trail started working. the fact that these pages happened to be Views pages seems to have been a red herring.

Was also hit by this but my case is like described in #11 and #16. I have taxonomy_menu and my term page is generated from a view. So if I understand correctly in this case the issue is in Taxonomy Menu (#3376390) and not this core issue?

EDIT: Was using 'taxonomy/term/%taxonomy_term' instead of '/taxonomy/term/%' as view path so the view route was used instead of the canonical from the term. So my mistake, that fixed it for me.

Crediting stefan.butura from the duplicate #3388353: Active trail not calculated correctly for Views menu items

Fully agree with #45. Have the same issue with active trail for menu items that duplicated multiple times ( they all are enabled ), some of them have 1 level in menu tree, some 2 ( all menu items located in `main` menu ).

Because of that, on node page for this menu item - I don't have second main menu that configured to show 2 level or greater.

Is there any quick solution for this (without deleting duplicates)? I've tried #30 on Drupal 9.5.1 but it's not work for me (patch applied but nothing changed).

@ever-c0de Thanks for validating my bug from #45 in #49! What I haven't been able to identify is whether this part of the bug existed before the Drupal 9.5.9 update or not, which might help determine if this is part of the regression noted here, or it is a long standing bug that deserves a separate issue.

I had do to the same thing as in comments from #42. Specifically, add in the view_id and display_id parameters.

Before:

$links = $this->menuLinkManager->loadLinksByRoute('view.courses.page_3', [], 'main');

After:

 $links = $this->menuLinkManager->loadLinksByRoute('view.courses.page_3', [
                                'view_id' => 'courses',
                                'display_id' => 'page_3',
                            ], 'main');

Concerning menu_breadcrumb, I posted a patch which does the trick for me.

I will provide a small update regarding #49. I fixed my own issue with active trail by decorating menu.active_trail service /Drupal/Core/Menu/MenuActiveTrail.php and changed getActiveLink method to have last link from $links variable.

This how it's looks:

      /*
       * Select the last matching link. I've done this because of duplicated
       * menu items.
       * On some block-menus we have set second depth of menu items.
       * If we have two identical menu items in one menu - it will not appear
       * because first link is selected (with lower(0) depth).
       */
      if ($links) {
        $found = end($links);
      }
    }
    return $found;

Basically, i've just changed $found = reset($links); from parent to $found = end($links); in my case. So, we receiving sorted by depth, weight and ID $links array from $this->menuLinkManager->loadLinksByRoute and in case we will have more than one link - the link with more depth will be active.

Patch helps me on 10.1.5 where in_active_trail was not getting called in my twig template.
Thanks!

I have same or similar problem when adding a view to the menu via the Views UI where in_active_trail does not appear to be showing true.

Drupal 10.1.6

Adding via Menu UI works fine.

Steps to reproduce:

1. Set up a view
2. Add it to the main menu via the Views UI
3. On front end active class should be added to a href and list item
4. When walking through the code, notice how in_active_trail is set to false even it is currently in_active_trail

Screenshots here https://www.drupal.org/project/drupal/issues/3404791

For what it's worth, the patch in #38 applies with a few small offsets to Drupal 10.1.7 and fixes the problem of active-trail not being applied to menus for View pages.

#38 works on 10.2.2 with a taxonomy menu for the first set of terms, but does not work for nested terms.

Edit: my mistake, I hadn't configured the taxonomy menu correctly and those terms didn't have menu items. The patch does work.

Would be great to have this bug fix in next minor or patched version of Drupal.

#38 works for me.

@2dareis2do the patch here doesn't apply and there is no MR, so what is RTBC?

@catch sorry my bad. I thought I had the patch applied locally but I don't think I have.

Rerolled patch with correct path. Not sure if this has changed recently but seems to be consistent now between applying patch to core or contrib, i.e. relative. In this case relative to core

@catch, I am not sure why the latest patch is not applying.

Works fine for me locally.

My feeling is that the CI and subsequent tests are broken.

Created merge requests for 11.x and 10.2.x from patch at #38.

Setting back to RTBC since there were no changes and the CI tests passing.

I'm not sure what the process is for removing BC changes (e.g. the route provider check in MenuTreeStorage and test) but that check is still in the 11.x MR.

#3381929: Restrict access to empty top level administration pages for overview controller adds an @todo item to remove some fallback code once this issue is committed.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

switching back to RTBC as this patch has been confirmed as working.

https://git.drupalcode.org/project/drupal/-/merge_requests/6493

Problem with CI bot?

As #72 and the issue commited first #3381929: Restrict access to empty top level administration pages for overview controller

@andypost, please can you explain why you have changed this to needs work?

If I understand correctly, that change is dependent on this one being committed (merged)?

Sorry in advance for the "noise" but can someone give a a summary of where things stand with this REGRESSION? I feel like it is not getting the proper attention from core maintainers that it should? Or am I wrong in that impression.

I see two MRs. One is marked for Drupal 10 and the other, I assume, is for Drupal 11? I suppose work has stopped completely on 9.5.x even though this regression was introduced in 9.5.9?

Also, I think there is still problem with menu items that reference a view that has a contextual filter. I recall others discussion that, but I don't know if it was in this issue or another.

-------

Update: my apologies for the rudeness of my message above. :)

• I was able to apply the patch at #30 to Drupal 9.5.11.
• My problem with views that have a contextual filter seems to have been introduced by a custom hook_menu_links_discovered_alter function that doesn't seem to be needed anymore.

@JonMcL, thanks for asking about this issue. There are thousands of open core bugs, and thousands of potential core contributors -- including you. 🙂 We fix thousands of issues a year, but there are still many more out there. What gets fixed and when depends on contributors stepping up to complete the work needed to complete the issue.

Drupal 9 is end of life and insecure, so it does not receive any further commits. You should upgrade to Drupal 10 as soon as possible to avoid security vulnerabilities with your site.

All merge requests should be created against 11.x (which is our main development branch). We should close other merge requests that don't target 11.x. If and when this issue has a fix that is ready for commit, it will be committed to 11.x first, and then backported to the actively supported branches of core according to our backport policy. In the case of this particular issue, the fix appears to be complex and to require internal API changes, so it might be committed to minors only (which would mean it would be available in 11.1.0 and 10.4.0 if we manage to fix this in the next five months).

Some sites use composer-patches to run interim/partial fixes until a proper fix is available in a stable release.

Thanks!

Can anyone explain why this has been set to needs work?

Patch here works for me without issue.

Can anyone explain why this has been set to needs work?

It is needs work for comment #72.

Also proactively tagging for IS update, since we're missing a proposed resolution. Would be good to update the IS to the latest state before setting to needs review again as well, otherwise the issue will surely fail the review for that.

Might just be tired but I'm failing to understand what is going on/what the request is for the @todo referencing this issue in MenuAccessTest::testSystemAdminMenuBlockAccessCheck(), could someone take a look?

@quietone, @wells I was also confused by #72 but removed the fallback code and rebased both MRs.

Cool. Doesn't apply to 10.3 now. Love these MR patches. Wrong issue

Patch for 10.2 does not apply to 10.3 afaict.

After updating to 10.3.1, I am no longer sure if this patch is required?

Certainly the other dependent issue appears to be marked as fixed and has been closed.

Disabling for now.

re-rolling patch for 10.3

~2dareis2do - We are still using the patch from #30 in production on 10.3 . Haven't tried the newer patches.

Thanks @nicrodgers

One issue I appear to have with this patch is the active trail does not remain active if you click on a sub page or path.

e.g. If I have a view for /news the active trail shows if I click on the news page at /news, mark up looks like so

<li class="nav-item active">
                          <a href="/news" title="Streatham News" class="nav-link active nav-link--news is-active" data-drupal-link-system-path="news" aria-current="page">News</a>
              </li>

However if I then click on a sub page the active class is no longer applied. e.g. if i go to a page at /news/data-reveals-neighbourhoods-most-need-lifesaving-defibrillators the actual active class(es) seem to disappear. I am not sure this is correct.

e.g.

<li class="nav-item">
                          <a href="/news" title="Streatham News" class="nav-link nav-link--news" data-drupal-link-system-path="news">News</a>
              </li>

In this case the sub item is not in the menu path, but, it is still the active section.

Also, for me, the active class is being applied in bootstrap, which is what I have based my front end theme on. This will likely vary for others depending on your theme. In my case. e.g:

.navbar-nav .nav-link.active, 
.navbar-nav .nav-link.show {
color: var(--bssk-navbar-active-color);
}

In this case the theme uses color (with no opacity) to set the visual active state. This is triggered by the use of the active class on the a link/href item.

Also, I have set up a home page content type and set this for my home page. One benefit of this approach is that I can set meta data on the node and also upload any required media etc there. However, I notice that if active, this only uses that is-active class.

I am a little confused why this is.

Ok so in web/core/includes/theme.inc

we have

/**
 * Prepares variables for links templates.
 *
 * Default template: links.html.twig.
 *
 * Unfortunately links templates duplicate the "active" class handling of l()
 * and LinkGenerator::generate() because it needs to be able to set the "active"
 * class not on the links themselves (<a> tags), but on the list items (<li>
 * tags) that contain the links. This is necessary for CSS to be able to style
 * list items differently when the link is active, since CSS does not yet allow
 * one to style list items only if it contains a certain element with a certain
 * class. I.e. we cannot yet convert this jQuery selector to a CSS selector:
 * jQuery('li:has("a.is-active")')
 *
 * @param array $variables
 *   An associative array containing:
 *   - links: An array of links to be themed. Each link itself is an array, with
 *     the following elements:
 *     - title: The link text.
 *     - url: (optional) The \Drupal\Core\Url object to link to. If the 'url'
 *       element is supplied, the 'title' and 'url' are used to generate a link
 *       through \Drupal::linkGenerator()->generate(). All data from the link
 *       array other than 'title' and 'url' are added as #options on
 *       the URL object. See \Drupal\Core\Url::fromUri() for details on the
 *       options. If no 'url' is supplied, the 'title' is printed as plain text.
 *     - attributes: (optional) Attributes for the anchor, or for the <span>
 *       tag used in its place if no 'url' is supplied. If element 'class' is
 *       included, it must be an array of one or more class names.
 *   - attributes: A keyed array of attributes for the <ul> containing the list
 *     of links.
 *   - set_active_class: (optional) Whether each link should compare the
 *     route_name + route_parameters or URL (path), language, and query options
 *     to the current URL, to determine whether the link is "active". If so,
 *     attributes will be added to the HTML elements for both the link and the
 *     list item that contains it, which will result in an "is-active" class
 *     being added to both. The class is added via JavaScript for authenticated
 *     users (in the active-link library), and via PHP for anonymous users (in
 *     the \Drupal\Core\EventSubscriber\ActiveLinkResponseFilter class).
 *   - heading: (optional) A heading to precede the links. May be an
 *     associative array or a string. If it's an array, it can have the
 *     following elements:
 *     - text: The heading text.
 *     - level: The heading level (e.g. 'h2', 'h3').
 *     - attributes: (optional) An array of the CSS attributes for the heading.
 *     When using a string it will be used as the text of the heading and the
 *     level will default to 'h2'. Headings should be used on navigation menus
 *     and any list of links that consistently appears on multiple pages. To
 *     make the heading invisible use the 'visually-hidden' CSS class. Do not
 *     use 'display:none', which removes it from screen readers and assistive
 *     technology. Headings allow screen reader and keyboard only users to
 *     navigate to or skip the links. See
 *     http://juicystudio.com/article/screen-readers-display-none.php and
 *     http://www.w3.org/TR/WCAG-TECHS/H42.html for more information.
 *
 * @see \Drupal\Core\Utility\LinkGenerator
 * @see \Drupal\Core\Utility\LinkGenerator::generate()
 * @see system_page_attachments()
 */
function template_preprocess_links(&$variables) {
...

In my case is-active class is only being applied to li elements.

Also adding the following css:

.navbar-nav {
  .nav-link.is-active {
    color: var(--#{$prefix}navbar-active-color);
  }
}

is-active seems to be applied more consistently.

There are exceptions. e.g. for me /user does not have active or is-active class applied. That is complicated by the fact that the path is /users/[myuser] despite the menu item for login being user. Still, at least the login path respects the is active trail. Modifying login markup like so in my theme:

{#
/**
 * @file
 * Boostrap SASS Starter Kit's override to display Menu Account.
 *
 * Available variables:
 * - menu_name: The machine name of the menu.
 * - items: A nested list of menu items. Each menu item contains:
 *   - attributes: HTML attributes for the menu item.
 *   - below: The menu item child items.
 *   - title: The menu link title.
 *   - url: The menu link url, instance of \Drupal\Core\Url
 *   - localized_options: Menu link localized options.
 *   - is_expanded: TRUE if the link has visible children within the current
 *     menu tree.
 *   - is_collapsed: TRUE if the link has children within the current menu tree
 *     that are not currently visible.
 *   - in_active_trail: TRUE if the link is in the active trail.
 */
#}
{% import _self as menus %}

{#
  We call a macro which calls itself to render the full tree.
  @see http://twig.sensiolabs.org/doc/tags/macro.html
#}
{{ menus.menu_links(items, attributes, 0) }}

{% macro menu_links(items, attributes, menu_level) %}
  {% import _self as menus %}
  {% if items %}
    {% if menu_level == 0 %}
      <ul{{ attributes.addClass('nav', 'navbar-nav')|without('id') }}>
      {% for item in items %}
        {%
          set classes = [
           'nav-link',
            item.in_active_trail ? 'active',
            item.url.getOption('attributes').class ? item.url.getOption('attributes').class | join(' '),
            'nav-link-' ~ item.url.toString() | clean_class,
          ]
        %}
          <li{{ item.attributes.addClass(classes) }}>
          {%
            set link_classes = [
              not menu_level ? 'nav-link',
              item.in_active_trail ? 'active',
              item.below ? 'dropdown-toggle',
              item.url.getOption('attributes').class ? item.url.getOption('attributes').class | join(' '),
              'nav-link-' ~ item.url.toString() | clean_class,
            ]
          %}
          {% if item.below %}
            {{ link(item.title, item.url, {'class': link_classes, 'data-bs-toggle': 'dropdown', 'aria-expanded': 'false', 'aria-haspopup': 'true' }) }}
            {{ menus.menu_links(item.below, attributes, menu_level + 1) }}
          {% else %}
            {{ link(item.title, item.url, {'class': link_classes}) }}
          {% endif %}
        </li>
      {% endfor %}
      </ul>
    {% endif %}
  {% endif %}
{% endmacro %}

tbh I am not sure why /user gets redirected to /users/ ?

It's possible to disable user redirect from path aliases.

That said, it still redirects user from /user/ to user/# so same problem with sub paths

ok turns out that I can use https://www.drupal.org/project/menu_trail_by_path

#38 no longer apply to 10.3.5

Patch #91 applies OK, and fixes the problem for me, thanks!

(You have to apply it in drupal/web/core)

Attach a patch that is a re-roll of #30 to latest 10.3.x (ie 10.3.5). This applied for me correctly, but note it does not include the workspaces patch.

Rerolling 100 for latest 10.3.x

Rerolling 100 for latest 10.4.x

Fixing #102

Rebased 3359511-regression-missing-menu onto latest 11.x

I'll set to Needs review to get further review on the deprecation message.

Patch from #103 fixed the issue for me on Drupal 10.4. Thanks all.

Rebased again as #3487851: Replace \PDO::FETCH_* constants to indicate fetch mode with an enumeration was merged.

Failing tests:

- Drupal\Tests\file\Functional\DownloadTest::testPrivateFileTransferWithoutPageCache()
- This seems like the approach/resolution may have a security-related issue.
- Drupal\Tests\standard\FunctionalJavascript\StandardPerformanceTest::testAnonymous()
- The test assertion should be updated.
- Drupal\Tests\settings_tray\FunctionalJavascript\SettingsTrayBlockForm::testBlocks()
- Seems to be consistently failing with the patch/merge request.

I've just tested MR 6493 and it has solved my issues.

I was getting the message "You do not have any administrative items." on my route:

inline_block_audit.custom_cms_audit:
  path: '/admin/reports/custom-audit'
  defaults:
    _controller: '\Drupal\system\Controller\SystemController::systemAdminMenuBlockPage'
    _title: 'Custom CMS Audit'
  requirements:
    _permission: 'access administration pages'

Thanks for fixing this!

Amending attribution.

I reworked patch #103 for Drupal 11.2.2

I've updated the PHPUnit test in order to pass.
Also ran the test only changes.

I've created a patch for 10.4.x without fixing some of the tests available here.

Need to update the Merge request against 11.x so that the PHPUnit tests pass and change the deprecation target to the next minor 11.3 and the removal as 12.

I've updated the change record to show a code example, and changed the deprecation target and removal version numbers to reflect updated code.

See https://www.drupal.org/node/3364323

Update summary:

• I've added a new patch with all changes to be used with 11.x
• I've updated the Issue Summary for clarity
• I've updated the Change Record to add examples.
• Adjusted the constructor signature of MenuTreeStorage:
  • Allowed the $route_provider parameter to accept RouteProviderInterface|array|null for backwards compatibility.
  • Deprecated passing an array (formerly used for $options) or omitting the parameter entirely.
  • This deprecation will be enforced strictly in 12.x.
• Updated WorkspacesMenuTreeStorage::__construct() to pass the route provider explicitly to match the parent constructor changes.
• All tests now pass, including new deprecation coverage added in MenuTreeStorageTest.

Restored original proposed resolution and added some additional details to the issue summary.

Adding patch that doesn't update tests

Patch #115 works for me (using Drupal 10.5.2).

Patch at 121 applies against 11.2.5, and solves the problem.

Is there a reason why this cannot be moved to RTBC? Multiple people report this solves their problem.

Looks like MR 6492 needs to be rebased for merge conflicts, then someone needs to review the MR.

I think #128 has put this into the MR

Applied MR #6493. Applied without conflicts and resolved issue.

Correct me if I'm wrong, but MR 6493 doesn't include the work above (especially #121) to make this work with Drupal 11.

@pcate, did you apply MR #6493 to a Drupal 11.x site with success?

The tests are failing on merge request #6493 so this needs to be back to Needs work.

That's because MR #6493 is based against Drupal 10 code.

The code to review was MR #6492.

Sorry, I typoed the MR I was referencing. 6492, the MR for Drupal 11, is failing tests so this should be Needs work.

I added a couple of tags and left a review comment on the merge request 6492 to replace the use of deprecated annotations with the noted PHP attributes in order to get the tests to complete again.

I reviewed the remaining tasks in the issue summary and updated them because there is a kernel and functional test now.

After fixing the merge request, if the next step is unclear, please remove the Novice tag.

Hello @marcoliver

Are you working on this in Vienna as part of the mentored contribution?

Oops, no, sorry! Hadn't seen that this had been tagged for Vienna. I'll stay off it for now.

Thank you for updating the merge request, @marcoliver.

The tests and test results are running again for 11.x, and BreadcrumbTest is failing so this is still Needs work. I removed the Novice tag for now as that task has been resolved.

Snapshot of latest state of MR for safe usage with composer patches on D11.3+ projects

Snapshot of latest state of MR (without tests) for safe usage with composer patches on D11.2 projects

• Updated MR !6492 with latest 11.x commits
• Addressed merge conflicts related to changes made in11.x for #3551446: Rename the workspace association service to workspace tracker (workspaces.services.yml) and #3518992: Config overrides are loaded for English even when translate_english is false (OpenTelemetryAuthenticatedPerformanceTest in demo_umami profile)
• Made some test fixes

Attaching current MR diff as patch usable with composer patches for 11.3.x.

Thank you, @casey and @joegraduate. Everything is green now so I think this is RTBC again.

MR 6942 has merge conflicts that need resolving

I've resolved the merge conflict in !MR6942 and set this back to needs review.

For the merge conflict I referenced this commit https://git.drupalcode.org/project/drupal/-/commit/223992a21c0d1e976f53d...

Previous versions of this PR attempted this change:

Commits to 11.x while this MR was stuck in review.

See https://git.drupalcode.org/project/drupal/-/commit/223992a21c0d1e976f53d...

The current version looks like this

Hopefully the screenshot help everyone understand my changes. I did not test with any other number, but all tests currently pass See https://git.drupalcode.org/issue/drupal-3359511/-/jobs/7866723#L307

Thank you for making the change. I also noticed that we were decreasing by 1 the number of queries in that test.

Changing back to RTBC.

The branch does not apply to main.

Some comments on the MR to address while fixing the merge conflict. The deprecation version also needs to be bumped to 11.4.0.

Needed a fixed D10 patch. This is based on the 10.4.x branch of the D10 issue fork but also applies on D10.6.

I have rebased MR !6492 onto the current main branch.

As this is my first time working on a core issue, I accidentally rebased on the fork's 11.x branch initially, which has caused some history noise. Sorry about that.

Also here's a patch that targets 11.3.x

Edit: I managed to get it applied to 11.3.9.

I'm having trouble applying #155 to 11.3.8 and 11.3.9.

from composer install -vvv

    https://www.drupal.org/files/issues/2026-05-11/3359511-155-11.3.x.patch ([regression] missing menu active trail in Drupal 9.5.9 (https://www.drupal.org/project/drupal/issues/3359511))
Downloading https://www.drupal.org/files/issues/2026-05-11/3359511-155-11.3.x.patch
patch '-p2' --no-backup-if-mismatch -d '/var/www/html/web/core' < '/tmp/6a0370037cf09.patch'
Executing command (CWD): patch '-p2' --no-backup-if-mismatch -d '/var/www/html/web/core' < '/tmp/6a0370037cf09.patch'
patching file profiles/standard/tests/src/FunctionalJavascript/StandardPerformanceTest.php

patching file modules/system/tests/src/Functional/Menu/BreadcrumbTest.php

patching file modules/workspaces/workspaces.services.yml

patching file lib/Drupal/Core/Menu/MenuTreeStorage.php

patching file profiles/demo_umami/tests/src/FunctionalJavascript/OpenTelemetryAuthenticatedPerformanceTest.php
Hunk #1 FAILED at 128.

1 out of 1 hunk FAILED -- saving rejects to file profiles/demo_umami/tests/src/FunctionalJavascript/OpenTelemetryAuthenticatedPerformanceTest.php.rej

patching file tests/Drupal/KernelTests/Core/Menu/MenuTreeStorageTest.php

patching file core.services.yml
patching file profiles/demo_umami/tests/src/FunctionalJavascript/OpenTelemetryNodePagePerformanceTest.php

patching file modules/workspaces/src/WorkspacesMenuTreeStorage.php
patching file modules/system/src/Access/SystemAdminMenuBlockAccessCheck.php

   Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2026-05-11/3359511-155-11.3.x.patch