Provide a way to prevent the navigation bar taking over local tasks

One can remove the top bar globally by removing this line https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/navig...

Or using a custom module with following hook.

<?php

namespace Drupal\nav_custom\Hook;

use Drupal\Core\Hook\Attribute\Hook;
use Drupal\Core\Hook\Attribute\ReorderHook;
use Drupal\Core\Hook\Order\OrderBefore;
use Drupal\navigation\Hook\NavigationHooks;

/**
 * Hook implementations for nav_custom.
 */
class NavCustomHooks {

  /**
   * Implements hook_page_top().
   *
   * Disables the Navigation top bar that was added by the navigation module.
   */
  #[Hook('page_top')]
  #[ReorderHook('page_top', class: NavigationHooks::class, method: 'pageTop', order: new OrderBefore(['nav_custom']))]
  public function pageTop(array &$page_top): void {
    unset($page_top['top_bar']);
  }

}

Moving this to a task.

I think there are two parts to this - firstly whether we want to make the top bar as a whole configurable. I think a decision was taken not to do that, but I've seen several people ask about it in slack.

The second part is whether it should be possible exclude specific primary tabs from the top bar when they're intended to be visitor facing, I definitely have sites where there are related landing pages linked together with primary tabs.

I have a use case where the primary tabs are part of the user interface and I don't want the navigation top bar to intercept and move them.

One possible option would be to support an extra key in links.tasks.yml to indicate that the task is for site navigation rather than administrative, and then have navigation module ignore those tabs. I don't know if we could do that selectively though - e.g. some tabs left and some moved into the top bar, although that seems potentially valid too.

Let's have an issue summary update here based on on #5

@iancawthorne I'm using this custom patch to disable top bar and restore tabs

Yes, the patch works perfectly.

Of course, I would be great to either habe this option in the module.

Or is it possible to also add have the local tasks reinserted through a custom module?

I would suggest, as an addition to the option of turning the topbar on or off, to have the possibility to turn it on/off depending on user role. I have a few use cases where it is good to have for admins and content creators. But not preferred for authenticated users.

Patch #8 is not moving the local actions back in place.

@mortona2k could you attach a screenshot?

The title is used as the commit message and should be descriptive of the change.

Attempting a title rename. And linking a slack discussion where this came up again:

https://drupal.slack.com/archives/C1BB308HH/p1778495710861299?thread_ts=...

A couple of things came up in the slack discussion:

1. We could provide an API at the local task level to prevent a local task being moved to the top bar. An example would be where a site uses local tasks for anonymous facing navigation and you want to preserve that appearance for admins (but other tabs on the page could be moved).

If we provide that API, it would become very easy for a contrib module to alter local tasks so none of them end up in the toolbar. There could be complications with tasks like the default 'view' tab on entities that possibly need to be in both places but I think that could be handled.

2. @rkoller brought up a usability meeting where it was discussed that the behaviour shouldn't happen at all within the admin theme. This would likely be a very straightforward core patch and could likely use its own issue and write-up.

Midcamp 2026, I'm working with @paul mosincat & @mradcliffe. We will update the issue summary & understand the issue in more depth.

midcamp2026, I am working with @mradcliffe and @mhasan14 to update the issue summary. @mradcliffe is helping to update this issue.

I'm adding the MidCamp2026 tag and working with a table here at the event. We're mainly going to be in MidCamp slack, but I'm available on drupal slack.

MidCamp2026 I'm working with @paul mosincat & @mradcliffe & @mhasan14 We will update the issue summary & understand the issue in more depth.
I like it here I love it here I finally found a home huah!

MidCamp2026. I am working with @mradcliffe, @paul mosincat, @mhasan14, @bluedman70

@ivnish - With the patch, the Add group type button is missing from the Group types admin page.

Same for content type add button.

Good luck MidCamp people, I believe in you!

midcamp 2026. i am working with @kkho01 , @bluedman70 , @mradcliffe issue updates will be provided

Midcamp 2026 Contribution Day @paul & I are leaving for the day, we have made a document and collaborated with our group for resolutions and a proposed issue summary update. Here's a link provided for our group collab and ideas! @mradcliffe @bluedman70 @prince gerald @kkho01

https://docs.google.com/document/d/1IcCDQfyWfSB5WScOvRxLZh9VFhty2Rh0kSBC...

@mhasan14 and I are leaving midcamp2026 for the day. We created a Google Doc with some potential ideas. Our fellow contributors: @bluedman70, @kkho01, @mradcliffe, @prince gerald are working on finishing these ideas and contributing on this.

link: https://docs.google.com/document/d/1IcCDQfyWfSB5WScOvRxLZh9VFhty2Rh0kSBC...

I removed the tag, but it probably will need to be re-added as the issue evolves.

I think we as a group are done working on this issue today. Thank you everyone at MidCamp and @rkoller for assisting in overseeing things.

We decided that we would take @rkoller’s question for @catch about #2 being a follow-up issue as actually doing that.

mhasan14 did use generative AI to help create some of the drafts, which were then edited and reviewed by @kkho01, @iprince, and @mradcliffe