You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Building a custom navigation menu is fiddly. We have in various versions explored surfacing a List View interface for managing and building the contents of your navigation. Let's surface the list view in the inspector.
When no menus exist
In this state, all pages (Page List) is shown:
A single menu exists
In this state, this one menu is loaded by default:
Multiple menus exist
In this state, the context defines which menu is loaded by default. If the navigation block is inside the Header template part, "Header navigation" is loaded by default, even if "Navigation" and "Navigation 2" also exist.
To facilitate discoverability of this inspector interface, we should try to enable the click overlay on the navigation block, just like it is for template parts in the site editor. That way the first click on your navigation will always select the full block, and surface the inspector interface.
See also #40204 for an adjacent effort to divide the inspector into tabs, which will be useful for 30+ items in a navigation block.
This issue was updated Sep. 28.
See initial proposal
What problem does this address?
Many users, both new and existing, have found the navigation block difficult to use. For new WordPress users, there are certain UI quirks that get in the way and jumping from parent to child blocks is challenging. For existing WordPress users who are new to FSE, there is a unique mix of directly editing the nav block (which is a new paradigm) and editing menus globally using the navigation sidebar.
What is your proposed solution?
inspector.mp4
Id like to propose that we simplify by leaning more heavily into editing menus locally/on canvas via the navigation block and emphasise template parts / re-usable blocks / synced patterns as the primary way of editing site elements globally.
A quick way of moving in this direction is simply moving the menu management experience into the navigation block settings sidebar, and removing the existing global navigation sidebar. We'd also enable adding navigation menu items from this management experience which removes the need to jump in and out of child blocks. Adding menu items makes use of the existing add menu item dialog. Menu editing can still be done directly on canvas, in this case I think the redundancy is fine.
The video shown here makes use of some of the ideas found here, namely surfacing child layers within patterns (e.g. header) which may be a more accessible way of selecting the navigation block for low tech users.
On top of the above change, a few other optimisations to make:
The add menu item dialog removes the ability to transform from the menu item selection stage and instead adds a back button
As seen in the screenshot above, the navigation toolbar can block menu selection when in an empty state
It also partially covers up the new block button as shown below
This may just be a me issue but I've found the current state very buggy. Selecting the navigation block sometimes puts the editor into an unusable state, preventing me from selecting any other layer. Video attached.
broken-nav.mp4
I realise this contradicts from this issue somewhat but if we introduce the idea of browsing/searching content in the sidebar then a dedicated UI for editing menu's becomes less important. We could still provide a way for managing menus outside the editor if there is value beyond just not having to enter the editor.
Building a custom navigation menu is fiddly. We have in various versions explored surfacing a List View interface for managing and building the contents of your navigation. Let's surface the list view in the inspector.
When no menus exist
In this state, all pages (Page List) is shown:
A single menu exists
In this state, this one menu is loaded by default:
Multiple menus exist
In this state, the context defines which menu is loaded by default. If the navigation block is inside the Header template part, "Header navigation" is loaded by default, even if "Navigation" and "Navigation 2" also exist.
To facilitate discoverability of this inspector interface, we should try to enable the click overlay on the navigation block, just like it is for template parts in the site editor. That way the first click on your navigation will always select the full block, and surface the inspector interface.
See also #40204 for an adjacent effort to divide the inspector into tabs, which will be useful for 30+ items in a navigation block.
This issue was updated Sep. 28.
See initial proposal
What problem does this address?
Many users, both new and existing, have found the navigation block difficult to use. For new WordPress users, there are certain UI quirks that get in the way and jumping from parent to child blocks is challenging. For existing WordPress users who are new to FSE, there is a unique mix of directly editing the nav block (which is a new paradigm) and editing menus globally using the navigation sidebar.
What is your proposed solution?
inspector.mp4
Id like to propose that we simplify by leaning more heavily into editing menus locally/on canvas via the navigation block and emphasise template parts / re-usable blocks / synced patterns as the primary way of editing site elements globally.
A quick way of moving in this direction is simply moving the menu management experience into the navigation block settings sidebar, and removing the existing global navigation sidebar. We'd also enable adding navigation menu items from this management experience which removes the need to jump in and out of child blocks. Adding menu items makes use of the existing add menu item dialog. Menu editing can still be done directly on canvas, in this case I think the redundancy is fine.
The video shown here makes use of some of the ideas found here, namely surfacing child layers within patterns (e.g. header) which may be a more accessible way of selecting the navigation block for low tech users.
On top of the above change, a few other optimisations to make:
broken-nav.mp4
I realise this contradicts from this issue somewhat but if we introduce the idea of browsing/searching content in the sidebar then a dedicated UI for editing menu's becomes less important. We could still provide a way for managing menus outside the editor if there is value beyond just not having to enter the editor.