Navigation Overview: Phase 2 priorities

[mtias]

This issue captures the current priorities for Navigation which we are aiming to include in WordPress 6.2.

Some progress has been made in 6.1, particularly on the theme switching, fallback and new menu facets. Editing menus is now an area that now requires attention.

There's also a longer backlog used to more exhaustively track open issues, bugs, and pending tasks at #38275.

Editing Menus

There are other questions around how to normalize things like "page list" (automated list) and individually curated items, how we handle transitioning from one to the other mechanism, etc. The flows for managing a menu extend beyond the menu itself (as in, it also needs to be taken into account when creating content like pages) and that's important to recognize.

• Navigation List View: Introduce navigation editable tree view in the inspector controls #42257 ⚠️

This work for 42257 can be broken down into discrete pieces, some of which can be done in parallel. These in a rough priority order:

• Create list view in the block inspector as an experiment (Off canvas menu editing: adds list view to navigation block #44534)
• Navigation List View: Conditionally enabled/disable block selection in the canvas #45440
• Navigation List View: Add an "edit" option #45442
• Navigation List View: Create a drill down navigation panels system #45439
• Navigation List View: Add a “create submenu” option #45441
• Navigation List View: Add a block appender #45445
• Page List: Display items in the List View #45482
• [Navigation Block] Experiment: Change focus when we edit a menu item to the correct tab #45951

---

At this point we can do some user tests

---

• Navigation List View: Move the navigation selector to the dot menu #45444
• Navigation List View: Handle the wide sidebar #45446
• Navigation List View: Move the list view to a separate tab #45447
• Navigation List View: Drag and drop considerations #45448
• Improve empty menu state in Nav Offcanvas #46202
• Page List allows insertion of any child block #46224
• Use LinkControl in Navigation Link block controls #46217
• Utilise LinkUI component in Navigation Submenu #46207
• Nav Submenu block Link UI text control #46206
• Handle non-direct insertion in Nav offcanvas inserter #46203
• Navigation Link: Handle rich text better in the label #46055
• Use <Navigator> component on Inspector Controls "back" button UX #45884
• Navigation: Share layout code for both Page List Item and Navigation Link #46050
• Universal block inspector controls back button #46058
• Navigation: Don't use the "submenu" icon for the navigation submenu block when in the list view #46065
• Navigation: Move the "add submenu" item and add an icon #46072
• Page List: Lock icon in the inspector controls #46191
• Explore a more systematic approach to interactions that should / could hide the block toolbar #46192
• Nav off-canvas editor not offering the option to create a new page when it doesn't exist #46193
• Navigation Items: Add transform items in the inspector, a la Group/Row/Stack #46195

---

Nice to haves:

---

• Page List: Add parent parameter to show all child pages of current page #31063
• Navigation Focus Mode: Ability to access/edit Navigation Post items in isolation #37950 (see Add focus mode for Navigation Menus #39286) - it should be possible to link from wp-admin to editing navigation in template focused mode
• Navigation: Improve the experience for moving between "auto" and custom items #45450

[mrkdevelopment]

@mtias Is there a possibility of conditional headers being added to the roadmap?

Scenario: I have 10 header designs. 1 is a default, the other 9 are conditionally loaded on pages where I sent the condition.

I have a couple of simple examples to explain my thinking.

1. Landing Page

I have a landing page and want a different header for this landing page compared to the main site. How would this work with the new navigation / header tools? I want a specific header with custom navigation for these specific pages.

2. Logged in User

I want a conditional header for a logged in user that displays a specific header only when a user is logged in. Is this something that is possible? (I'm not talking about a login or logout block, but the whole header being changed)

3. Custom Header for Blog categories

I want to have a different header on different blog categories. I have 9 categories and can potentially design multiple headers to allocate conditionally.

Are these kinds of features within core or are we looking at these being the realm of third party plugins?

I read over the other tickets but these seemed to be limited to just login / logout and conditional navigation. Not the whole header section or other sections having multiple variations and conditionally being added to pages.

I'm not sure if this is the right place to comment so feel free to move this where it should be.

[mtias]

@mrkdevelopment sorry I missed the questions!

1. Unless I'm missing something, you'd just use a different header template for your landing page with whatever navigation items you need.
2. Not possible from the editor UI alone. Can you share how the menus would differ and what would they have in common (if anything) to clarify the need further? Would be good to open a new issue with this request specifically if you don't mind.
3. This should also be possible with category templates, which can be as specific or broad as you need them to be.

[scruffian]

I updated this issue with the latest priorities for phase 2.

[getdave]

Update 17th November 2022

I posted an update on the Tracking Issue to alert folks that progress for 6.2 will be tracked on this Issue. Read that update for details on progress.

Future updates on 6.2 progress will appear here.

[scruffian]

Update 1st December 2022

There has been good progress on the items in the issue description. We now have the basics of the Navigation List View working. It is possible to view, edit and remove navigation items from the inspector controls. Drag and drop also works. The main areas of concern are:

1. When editing an item, can we show the settings tab?
2. Can we animate the opening of the block settings to make it clear that this is conceptually a "drill-down" operation

These will be the next areas to focus on. Work is happening on this project board: https://github.com/orgs/WordPress/projects/60/views/1, which should give more detail on progress.

This video shows the current state of the project:
https://user-images.githubusercontent.com/275961/205058431-36250e48-bff3-42a7-a673-997a47d841d5.mov

The issue description will be updated to reflect the current outstanding issues.

[scruffian]

Update 12th December

This experiment is progressing well, we are now at a point where it can be tested by users, by enabling these two checkboxes:

The main features of the list view are working:

• The navigation list view is now in its own tab in the block inspector controls.
• Items in the navigation list view can be edited by drilling down into the inspector controls.
• Submenu items can be added in the navigation list view
• Items can be reordered in the navigation list view using drag and drop
• Page list blocks can be filtered by their parents
• The navigation list view can be opened from the block toolbar

Many of these features have been enabled by the offcanvas editor experiment. We're looking for feedback about whether this feature is valuable for users and therefore should be made a part of the default experience for the block.

[getdave]

Update 9th Jan 2023

Contributors are now largely back following the Christmas and New Year period.

With the feature freeze for WP 6.2 drawing ever nearer (early February 2023) we are looking to decide whether or not to merge the Offcanvas editor experiment into Gutenberg Core.

Based on the positive feedback received on the recent call for testing it's looking like we will be aiming for including the feature in WP 6.2. However this is based on many factors including whether we can achieve the work necessary to make the feature stable by the feature freeze.

The project board has been reorganised to reflect the priorities for stablising the feature. Project contributors will be focusing on this effort.

A reminder here are the calls for testing:

• Prototype
• Experimental implementation

[getdave]

Update 10th Jan 2023

I've created a list of current known accessible issues with the feature. These are being prioritised alongside other elements of fidelity.

[getdave]

Update 25th Jan 2023

Work continues to be heavily focused on the Nav block list view experience:

• Many of the key a11y issues have been address leading to an improved experience. Contributors continue to work on these.
• The block list view feature is due to come out of "experimental" and land in the Gutenberg Plugin. The aim is for this to attract more feedback.

[getdave]

Update 8th Feb 2023

Contributors continue to focus on resolving bugs for 6.2, including a11y related issues.

Other work is restarting in the background but is not yet up to speed.

[Marc-pi]

I've just tested "add the search block within the nav", and the XP is not nice !!!
see #48410

[getdave]

Update 8th March 2023

Contributors have been focused on last minute fixes to the Browse Mode Navigation sidebar as well as the Nav block list view editing mode. This is for WP 6.2.

Looking ahead beyond 6.2 contributors have been focused on:

• Fixes and optimisation on the block itself.
• Adding/improving automated test coverage.
• Exploring improving perceived block performance with server side preloading.
• Exploring auto-creation of Navigation menu fallbacks to improve resilience and loading experience.

[fabiankaegy]

Hi all 👋

I think #39644 should be tracked here

[getdave]

Hi all 👋

I think #39644 should be tracked here

It's tracked in #31452 I believe. Also the Tracking Issue is here.

[getdave]

Update 15th March

• Contributors have been helping out with the effort to stabilise the Navigation feature in the Browser Mode sidebar for WP 6.2. After much discussion the Navigation feature was dropped from 6.2 as of RC2 as it was deemed not polished enough for inclusion (see note below).
• The Navigation list view editing in the block itself is still included in WP 6.2.
• Lots of active discussion around pre-loading Navigation Menus to improve the editor loading experience. More feedback would be appreciated.
• Contributors are continuing to work on augmenting the e2e test suite for the block.

[Marc-pi]

Ahead of Browser mode that needs to be designed more globaly (incl. with the upcoming new admin menu in mind / as target)
i'm facing DAILY on projects those limitations during the editing flow, that should be IMHO on top priority if we think about end user and want to make competitive this component :

• add search block within nav > wrong display Navigation > add search block > description is mandatory and its style cannot be deactivated #48410 (impacts also wordpress.com / calypso [Block] Search: Button and Label options can't be changed when part of Navigation Block Automattic/wp-calypso#73860)
• manage burger icon size + upload custom icon, style it directly from block settings Add ability to style and/or use a custom icon for responsive menu  #37930
• style the dropdown from block settings when using submenus (width, background, padding/margin, shadow, border, etc.) / cannot find an issue on this, but it is a major point
• i did not test yet to add a separator within the menu (line), to build a mega menu like navigation, but it is needed in eCommerce projects, neither to add columns...

Some can be managed with custom css, but end users can be surprised not being able to manage this directly within the Editor.

Just to update the task list accordingly with this humble feedback ;-)
Let me know if more details are needed.

[getdave]

@Marc-pi Thank you for the feedback. Let's loop in @WordPress/gutenberg-design on these issues as well so that we can consider them holistically.

Know that we are listening, but as always we will have to balance these against other known issues, bugs, and necessary technical upgrades to the block itself.

Thanks again for taking the time to list these out for contributors. It's very useful and much appreciated.

[jasmussen]

add search block within nav > wrong display

I agree. This seems to have regressed from #31127, I don't have the context for why that is. We also need an icon-only display (#31128).

manage burger icon size + upload custom icon, style it directly from block settings

Also agree, with the immediate solution having already been explored, allowing the upload of icons. SVG turned out to be an obstacle because for security reasons you're not allowed to upload them. While this is something I think we should revisit, in the mean time I recall (but cannot now find) a PR that allowed uploading png files.

Agree with the remaining issues too — I'd love to both allow more customizability of all the pieces, and allowing more blocks inside. I'm excited about #43852 that would allow full customization of the contents inside the overlay menu, and I could see dropdown customizability starting out in theme.json and then a UI being surfaced later on. This might be worth opening a separate issue for, if one doesn't exist already.

[getdave]

Discussion on new priorities for 6.3

With 6.2 nearly released, we should start to look at priorities for 6.3. As I see it the items listed below are the key problems. Note these are high level items and many of them contain specific sub issues.

I would like to discuss this with other contributors:

Theming and Customisation

• Customise and control the Navigation block at different screen sizes ("responsive") #49156
• NavigationLink: make the URL dynamic for links to Posts #18345
• Improve theme.json support for Navigation block #39052
• Add a way to style current menu item in the Navigation block #23225
• Improve Navigation block color controls #44712

Creation and management

• Nav block use slug to reference Navigation Menu #45512
• Improve relevance and ordering of search results in Link UI and Navigation block #38121

---

See also the list of items in the Tracking Issue.

[getdave]

Update 29th March

• Contributors are looking at improving the stability of the fallback mechanic in the block by adding tests and consolidating all logic in a single place in the code. This is still a WIP ready for review.
• Contributors are continuing to work on high level "smoke" e2e tests intended to cover the functionality of the block at a high level. More fine grained tests will be added as unit/integration tests not requiring a full WP installation to run against.
• Contributors continue to compile and assess priorities for the 6.3 cycle.

[getdave]

Update 21st April 2023

Contributors have been working hard at improving the fallback mechanics for the block. This important foundation work has now merged which - due to the number of tests added - puts us in a much better position to move forward with other critical pieces of work.

Contributors are also going to try and agreed a set of key tasks to address for the 6.3 cycle. It's going to be tough as there are a number of competing priorities.

[getdave]

Update: I created a new overview Issue for 6.3 #50165

---

The tasks on this Issue are almost entirely complete. We should open a new Issue for 6.3 and beyond. The Tracking Issue is the source of truth.