New Toolbar Roadmap: Path to Beta & Stable

Thank you @ldonelan! I've updated the links to use the pattern for issue numbers so the state gets pulled automatically.

More issues added to define the plan better.

Bumped 📌 Revert to default in navigation layout settings from the UI Active down to "Could Have" as a lower priority non-MVP item, after discussion on the weekly Admin UI call. @ckrina to follow up with @laurii about this feature as well to get some clarity around it. More details in the ticket.

Adding 📌 Decide strategy to customize or provide 1st level menu items' icons Active as a Stable Must Have.

@ckrina, I reorganized tickets based on our discussion. Let me know if this looks OK or if you'd like a different format.

Updating with completed, specially to get a sense of missing tasks for the beta release.

From looking at https://git.drupalcode.org/project/navigation/-/commit/17970de1ed6b4129d... it looks like there is not yet a caching strategy for the menu links in the navigation module.

The existing toolbar has a very developed caching system already, this was implemented in #1814932: Caching strategy for D8 toolbar → , #1137920-303: Fix toolbar on small screen sizes and redesign toolbar for desktop → and #1805054: Cache localized, access filtered, URL resolved, and rendered menu trees → and has not significantly changed since.

It was necessary to add this because rendering a full tree of admin menu links is very expensive both in terms of server-side processing (hundreds of milliseconds every request) and page weight (potentially hundreds of extra kb every request).

I think we need an issue to port this logic across from the existing toolbar.

Thanks @catch! I've created the issue to keep track of it 📌 Implement a caching strategy for the menu links Active and added it as stable blocker.

Moving 📌 [META] Implement the final design system Fixed to done, and removing 🌱 [PLAN] Accessibility review Active from beta blocker as the reviews have started. Any issue found will be added as Stable blocker if necessary.
Also adding 📌 Remove postcss-px-to-rem from Navigation Active as it'd be a really nice cleanup to have.

Added a few more issues.

Removing the Beta section since everything needed for beta has been done and we're about to launch beta 3.

I moved 🌱 [PLAN] Accessibility review Active to the Should have, and if any Accessibility bug found becomes an Stable blocker it'll be included into the "Must have" section.

Updated with new stable blockers and removed fixed issues.

Adding 📌 Investigate using the core "User account menu" in favor of custom Navigation Block for same Active as stable blocker.

Added ✨ For RTL languages, Navigation menu should show on the right Active . IMHO is a "must" for stable, but we would want to check with RTL languages' native speakers.

Adding a new stable blocker: 🐛 Navigation layout Drag is not working in some browers Active .

Adding 📌 Mark Navigation as beta experimental Active as a reference for beta stability sign-offs.

📌 Decide strategy to customize or provide 1st level menu items' icons Active appears twice under the must have list, not sure if that was an oversight or if one of those was meant to be a link to a different issue?

Cleaning up the Stable blockers.

Moving 🐛 The toolbar should be usable without JS Needs work to the Should have section.

Added 🐛 Special Menu items are rendered as empty links in navigation RTBC

Adding 🌱 [META] Migrate Navigation to SDC Active and removing completed tasks.

May I ask why you removed the links to the issues, @ckrina?

- <li>
            
              
              
              🌱
              [PLAN] Icons for the sidebar
                Active
              
             (Ability to choose icons on the UI)</li>
+ <li>Ability to choose icons on the UI</li>

- <li>Environment Indicator</li>
+ <li>
            
              
              
              ✨
              Support for core navigation experimental module 
                Needs work
              
            </li>

Updating with the issues for core modules that need integrations.

Removing fixed issues.

Moving another one into the should have. This is not a critical action for the navigation itself, only if you want to customize it. It should get done, but not block this becoming stable.

Removing a fixed already issue.

There are two more issues that have originally been reported on in the feedback issue, that have not been prioritized yet:

• 🐛 Second level menu items can't be reached if they have children Active
• ✨ Navigating to first level menu items is not obvious Active

✨ Provide Config Action to add new blocks to navigation from recipes Active looks to me like it wouldn't need to be stable blocking too - it's not user-facing and it won't require any API deprecations or storage changes, just a small API addition. I realise it might be Drupal CMS blocking but that's different thing in terms of module stability.

Adding a couple of issues marked stable blocker that were not in the issue summary here under "Must Have".

Updating Top Bar Navigation blockers.

Added 🐛 Second level menu items can't be reached if they have children Active under "Could have"

Removing fixed issues! :D

✨ Provide Config Action to add new blocks to navigation from recipes Active

Updated top bar explanation based on discussion with @ckrina

Added 🐛 Layout Builder Create Inline blocks logic should be optional Active as Must have.

Removed 🐛 Layout Builder Create Inline blocks logic should be optional Active per conversation in Slack from Must have, dropped to Should have.

With 📌 Implement a caching strategy for the menu links Active RTBC, I am starting to think we could skip doing 📌 Implement a caching strategy for the menu links Active , especially if we can figure out 📌 Render the navigation toolbar in a placeholder Active . We probably want to check exactly how much HTML we're sending to the browser, but otherwise those two issues should speed things up considerably.

Discussed the above a bit more with @plopsec and swapped out 📌 Implement a caching strategy for the menu links Active for 📌 Render the navigation toolbar in a placeholder Active in the issue summary.

Adding 📌 Adjust how Help link and Content links are removed from the Administration menu for the Navigation bar RTBC as a should have.

Adding 📌 Evaluate if the Top Bar entity title needs to show extra Active as a should to have.

Cleaning up Stable blockers to simplify the review of missing work for stable release.

Adding 🐛 Styling of front theme affects styling of navigation buttons Active to the top of the should have list since it has a major DX impact.

Removing fixed issues.

Add un-tracked issues marked as Navigation blockers. Let's discuss if they are really blocking the release.

Removing 📌 Render the navigation toolbar in a placeholder Active because that's all done except for the big pipe-agnostic js follow-up which is in progress!

Really happy with how that all turned out - we can drop the old complex toolbar menu tree caching client side code, solving all the problems that tried to solve without introducing new ones like flicker, and also it's opened up significant new performance improvements for core at the same time.

Adding 🐛 The icon for the more actions button is not visible Active to the must haves since it's a major bug that makes it really hard to find actions besides "Edit".

Removing 📌 Integrate Navigation with Contextual editing Active from stable blcokers.

Bumping 📌 Adjust how Help link and Content links are removed from the Administration menu for the Navigation bar RTBC to Stable Blocker.

Adding the following recent stable blockers:

• 📌 Local task name expectation in getFeaturedPageActions is fragile Active
• 📌 Show the Navigation Top Bar in 11.1.x and 10.4.x Active

Downgrading priority of ✨ Fix safe triangle bottom position. Active to 'Could Have'.

Added the following under Top Bar:

• 🐛 navigation top bar edit button has strange active (?) colors Active
• 🐛 Navigation top bar overlaps with Olivero menu Active

Replaced 🐛 Styling of front theme affects styling of navigation buttons Active with 🐛 Front-end theme styles can bleed into Navigation Active

Added the following to 'Should have':

• 🐛 High contrast mode needs some more refinement Active
• 📌 Add a placeholder preview for the navigation toolbar Active
• 📌 [PP-1] Integrate the new Navigation Icon API with NavigationLinkBlock Postponed
• 🐛 Create content link missing after creating content type Active

Just bumping this because the issue summary issue status filter could use a refresh to see what's committed vs. not.

Moving 📌 Local task name expectation in getFeaturedPageActions is fragile Active to should have. That leaves one current stable blocker, which needs reviews.

Removing closed stable blockers (and issues from other sections) to make it easy to parse what's missing.

Removing closed stable blockers (and issues from other sections) to make it easy to parse what's missing.

Added references to #3516887: Allow to customize Navigation icons → and 🐛 Unchecking the content preview in navigation layout will change the navigation icon to text. Active

1. Settings tray also requires toolbar module.
2. Navigation suggests to uninstall toolbar module when navigation is used.

Is there a plan to resolve this somehow? I don't see a reference above to settings tray.

2. Navigation suggests to uninstall toolbar module when navigation is used.

I think Gin already supressed the message in: 🐛 Temporarily suppress toolbar & navigation warning Needs review . It was a workaround, because as per comment #7 from 🐛 Status warning: Toolbar and Navigation modules are both installed Active , it was not possible to uninstall toolbar module yet (not sure if that is still true these days).

I don't think the dependency between Settings Tray and Toolbar is fundamental so we could most likely get rid of that if we want to. At the same time, Settings Tray is at ~4-5% usage per 🌱 By default deprecate non-experimental modules that are used by less 5% of sites before the next major version Active . We should probably consider moving Settings Tray to contrib with Toolbar. People using it alongside Toolbar could continue using their current setup from contrib.

If people don't use settings tray then it is indeed better to move it out of core than to invest time into making Navigation and Settings Tray compatible somehow. Crossposting this info on 📌 [meta] Deprecate Toolabr module Active .

I prefer the administration menu to be at the top of the screen, and it looks like a vertical menu on the left side of the screen is the only option in the new Navigation ... The same position as in WordPress, which I am a not a fan of, since you have to hover, as well as click, and then click some more, to access a common task, such as node display configuration.

Ideally, it should be like Admin Toolbar → , where you hover your way over menu items, all the way to the destination. See 🌱 Usability Review from the UX Meeting (5 Apr 2024) Active for more feedback.

Is there an issue for switching the position of the Navigation menu from the side, to the top?

Also, Admin Toolbar users are uncertain what this means for that project, see 🌱 Future of Admin Toolbar if Toolbar is removed from Drupal core Active . Maybe Admin Toolbar could be restructured, and built on top of Navigation, instead of the Toolbar module? :)

Contributed modules can still provide toolbars at any other location with any other kind of interaction :)

It is a degradation in my opinion, and loss of a fundamental feature in Drupal core, to not offer an administration menu, which supports horizontal orientation.

The current Toolbar is flexible, and offers both a horizontally oriented menu at the top, while allowing the user to switch to a vertical orientation, in the left side, by clicking the arrow icons.

The new Navigation only has a menu in the left side, like in WordPress.

I think the new Navigation likewise should offer both a horizontally oriented menu at the top, as well as a vertical orientation. Where has this decision to shoehorn the user into using a left side menu been discussed, and on what basis was it decided?

Is there an issue?

PS. Yes, I know that contrib modules can extend Drupal core modules :)

I am curious why this issue is not considered as a stable blocker: 🐛 Second level menu items can't be reached if they have children Active ? A lot of contribs add new menu items to the Administration menu - for example Scheduler - and due to this Navigation module's limitation, it is not then possible to access some admin pages (see 🐛 Cannot access Taxonomy overview page via Navigation menu Active ).

Also I am not sure if that is a known issue (did not have time to search it yet, as I run into this just today), but on a clean Drupal 11.x, if you enable Navigation and then Workspaces UI, the site will crash with an error:

Drupal\Core\Render\Component\Exception\InvalidComponentException: [navigation:toolbar-button/icon] NULL value found, but an object is required. in Drupal\Core\Theme\Component\ComponentValidator->validateProps() (line 232 of core/lib/Drupal/Core/Theme/Component/ComponentValidator.php).

@ressa 🌱 Improve administration navigation Active . 2+ years of work with actual UX research, several DrupalCamp/DrupalCon sessions, including being highlighted in several Driesnotes. Didn't come out of the blue precisely.

I've added the two issues brought up by @poker10 as stable blockers.

I'm personally not sure about 🐛 Second level menu items can't be reached if they have children Active - can't you navigate via the admin page like admin/config itself, but haven't tried to reproduce directly yet, but we can always remove it from the blocker list again if it's determined not to be one.