[PLAN] New Navigation and Top Bar to replace Toolbar Roadmap: Path to 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 #3412123: Revert to default in navigation layout settings from the UI 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 #3432173: Decide strategy to customize or provide 1st level menu items' icons 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 #3438976: Implement a caching strategy for the menu links and added it as stable blocker.

Moving #3426606: [META] Implement the final design system to done, and removing #3391723: [PLAN] Accessibility review for new Navigation bar from beta blocker as the reviews have started. Any issue found will be added as Stable blocker if necessary.
Also adding #3428036: Remove postcss-px-to-rem from Navigation 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 #3391723: [PLAN] Accessibility review for new Navigation bar 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 #3441576: Add a new "Navigation user links" menu in favor of hardcoded links in NavigationUserBlock as stable blocker.

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

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

Adding #3443843: Mark Navigation as beta experimental as a reference for beta stability sign-offs.

#3432173: Decide strategy to customize or provide 1st level menu items' icons 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 #3396174: The toolbar should be usable without JS to the Should have section.

Added #3447837: Special Menu items are rendered as empty links in navigation

Adding #3458216: [META] Migrate Navigation to SDC and removing completed tasks.

edit: Sorry, misread the changes. All good.

Updating with the issues for core modules that need integrations.

Removing fixed issues.

Removing the icons from stable blocker. We want to have it but it shouldn't block Navigation from stable.

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:

• #3480321: Second level menu items can't be reached if they have children
• #3480322: Navigating to first level menu items is not obvious

#3478224: Provide Config Action to add new blocks to navigation from recipes looks to me like it wouldn't need to be stable blocking - 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 to 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 #3480321: Second level menu items can't be reached if they have children under "Should have"

Removing fixed issues! :D

#3478224: Provide Config Action to add new blocks to navigation from recipes

Updated top bar explanation based on discussion with @ckrina

Added #3485435: Make Layout Builder Create Inline blocks logic optional as Must have.

Removed #3485435: Make Layout Builder Create Inline blocks logic optional per conversation in Slack from Must have, dropped to Should have.

With #3493406: Add render caching for the navigation render array RTBC, I am starting to think we could skip doing #3438976: Implement a caching strategy for the menu links, especially if we can figure out #3493911: Add a CachedPlaceholderStrategy to optimize render cache hits and reduce layout shift from big pipe. 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 #3438976: Implement a caching strategy for the menu links for #3493911: Add a CachedPlaceholderStrategy to optimize render cache hits and reduce layout shift from big pipe in the issue summary.

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

Adding #3499783: Evaluate if the Top Bar entity title needs to show extra info as a should to have.

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

Adding #3486720: Styling of front theme affects styling of navigation buttons 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 #3493911: Add a CachedPlaceholderStrategy to optimize render cache hits and reduce layout shift from big pipe 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 #3505124: The icon for the more actions button is not visible to the must haves since it's a major bug that makes it really hard to find actions besides "Edit".

Removing #3465295: Integrate Top Bar Navigation with Contextual editing from stable blcokers.

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

Adding the following recent stable blockers:

• #3511612: Local task name expectation in getFeaturedPageActions is fragile for determining Top Bar featured actions
• #3507866: Enable the Navigation Top Bar when Navigation is enabled

Downgrading priority of #3442317: Fix issues with Navigation "safe triangle" positioning to 'Could Have'.

Added the following under Top Bar:

• #3501662: navigation top bar edit button has strange active (?) colors
• #3501507: Navigation top bar overlaps with Olivero menu

Replaced #3486720: Styling of front theme affects styling of navigation buttons with #3511280: Front-end theme styles can bleed into Navigation

Added the following to 'Should have':

• #3438477: High contrast mode needs some more refinement
• #3505610: Add a placeholder preview for the navigation toolbar
• #3507057: Integrate the new Navigation Icon API with NavigationLinkBlock
• #3503221: Create content link missing after creating content type

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

Moving #3511612: Local task name expectation in getFeaturedPageActions is fragile for determining Top Bar featured actions 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 #3509310: The AdminToolbar(Navigation) items are not clickable when we're on the navigation layout page.

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: #3493143: Temporarily suppress toolbar & navigation warning . It was a workaround, because as per comment #7 from #3489361: Status warning: Toolbar and Navigation modules are both installed, 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 #3158669: [policy, no patch] By default deprecate non-experimental modules that are used by less 5% of sites before the next major version. 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 #3484850: [meta] Tasks to deprecate Toolbar module.

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 #3439012: Usability review and feedback from testing 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 #3449462: Future of Admin Toolbar if Toolbar is removed from Drupal core. 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: #3480321: Second level menu items can't be reached if they have children? 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 #3495134: Disable Scheduler's views for taxonomy terms and media items because they are extraneous and break Navigation).

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).

//edit - found it #3511374: Core Navigation + Workspace + Workspace UI modules crashes Drupal Installation . I think this should also be a stable blocker.

@ressa #3364258: [meta] Improve administration navigation. 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 #3480321: Second level menu items can't be reached if they have children- 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.

Some cleaning up: removing #3391723: [PLAN] Accessibility review for new Navigation bar since the issues found there are the ones that need to be listed. Also moving #3396174: The toolbar should be usable without JS into a nice to have since it not that realistic to run Drupal without JS anymore.

And I tended to agree that #3480321: Second level menu items can't be reached if they have children wasn't a stable blocker but a lot of users are claiming it to be an important missing requirement and is almost there.

Removing #3511374: Core Navigation + Workspace + Workspace UI modules crashes Drupal Installation from the Stable blockers per @catch comment in the issue. Added it as a nice to have.

Sorry, I overlooked the specific error in the #3511374, but originally I meant this new issue: #3523705: InvalidComponentException when workspaces ui is installed as a stable blocker in #89.

Adding #3518662: Use a lazy builder/placeholder for the top bar to should haves.

Added #3540337: Improve visibility of More actions menu button as a child issue. It's different from #3505124: The icon for the more actions button is not visible.

I was uncertain whether I should change the IS here.

Just committed #3452724: Navigation side bar and top bar should have appropriate aria labels to 11.x and 11.3.x which means the last known stable blocker is fixed.

I'm a bit unsure about #3511612: Local task name expectation in getFeaturedPageActions is fragile for determining Top Bar featured actions so will ping UX/product managers about that one.

While we're doing final triage though, I think we need issues for the following:

1. Mark navigation as stable (remove the experimental flag, update d.o docs)

2. Use navigation in the standard and umami profiles.

3. Deprecate toolbar module (and the various sub-issues that will be required to do that).

Added #3505182: An entity without a label causes an uncaught exception for the navigation:title component and removed the last stable blocker.

Adding #3541688: Focus does not move to submenu when opened by enter or space key to should haves.

Adding the issue for the Documentation Core Gate requirement to the must have because that is where it really belongs, even though it was overlooked. Obviously not have up to date documentation is not ideal for the community but it also caused changes to standard practice when creating the release note for a new extension. Normally, the release note would direct to the online documentation, which makes for a concise note. However, since this was not possible xjm spent time creating a unique note which, of course, needed to be reviewed. It is unfortunate when we all miss requirements.

I think #3565213: Adjust contextual CSS for navigation module reset CSS is technically a contextual module issue, but IMO should be fixed before Navigation is added to Standard.

Also, maybe the title of this issue should now be "[PLAN] New Navigation and Top Bar to replace Toolbar Roadmap: Path to Standard". 🙂

Bumping the priority tag to current next version :)

There is now basic documentation. Improvements to it are welcome.

All issues tagged as "Navigation stable blocker" are fixed