Repository navigation
Navigation Sidebar as a discovery and editing surface #76037
Description
What
The "Navigation" section in the Site Editor's global sidebar — the panel that opens when clicking the WordPress logo — currently shows navigation menus in isolation. Users see the contents of a navigation block divorced from any site context: no accurate styling, no indication of which templates use the menu, and no clear path to editing the menu in its actual rendered context.
The experience is also functionally limited: users can reorder and delete menu items but cannot edit or add links from this view. The preview reflects only the raw menu data rather than the styles, layout, or behaviour defined by the surrounding template — which is of limited value to most users trying to understand how their navigation looks on the site.
A core goal of this work is to make it possible to manage navigation menus — adding, removing, and reordering items — entirely from this sidebar, without requiring users to navigate to the block editor or locate a Navigation block in a template. The canvas remains the right place for styling and layout; this section should handle the content of menus directly.
Why
When users visit this section, they typically want to:
- Find the menu that controls a specific part of their site's navigation
- Understand which menus are active and where they appear
- Make changes to a menu and see those changes in the correct context
The current experience fails all three. The isolated view gives users no way to know which menus are in use, where they appear on the site, or how they actually look. There is no clear path from this view to editing a menu in its real template context.
This has been a known gap for some time. User testing has reinforced that the current view creates confusion — particularly for users with multiple menus, who have no basis for distinguishing between them or understanding how a change to one menu will affect the rest of their site. #65828 recognised a similar need and explored DataViews-based UI patterns as a direction; this issue builds on that prior thinking and grounds it in explicit user requirements.
How
Discussion in the comments has produced a candidate approach, treating this section as both a discovery surface and an editing surface — two distinct but sequential phases of the same workflow.
Discovery phase
- A DataViews list of all navigation menus, with a "where used" field visible at a glance — showing which template parts reference each menu
- Each menu should have a clear active/inactive status — indicating whether it is currently in use anywhere on the site. This is distinct from post status (draft/published); a menu can be published but not actively used in any template
- For v1, scope is limited to template parts only; pages and other document types are out of scope initially, though the design should leave room to expand later
- Menus that are not yet used anywhere on the site are shown alongside active ones — the preview frame displays a placeholder in this case. This is important for users preparing menus in advance of activation
Editing phase
- Selecting a menu from the list shows a preview frame on the right, displaying the template part(s) where that menu is used. The interaction model draws on the page selector design explored in Include a page selector in the site preview to enhance the UX of global style #72497 — allowing users to switch between the page and template contexts in which their content appears — applied here to navigation menu locations
- An editable list view — consistent with the existing navigation block inspector sidebar — provides a full editing surface including adding and removing items. The appender defaults to page link blocks; non-link blocks (e.g. social icons) remain a canvas concern
- Individual menu item settings are surfaced via a popover, keeping the full menu structure visible while editing — not a drill-down that removes list context. This mirrors the content-only editing experience introduced for the navigation block
- Clicking a template part in the preview frame takes you directly into editing it in context, with a clear route back — breadcrumbs at every level, no dead ends
- The editable list view should feel and behave as close as possible to the equivalent experience in the navigation block's inspector sidebar — same task, two surfaces
Open Questions
The following questions are genuine open points. They are intentionally left unresolved here — the answers will come from prototyping and observation, not from further design discussion.
- Preview frame: all locations or one? Should the preview frame show all template parts where the menu is used simultaneously (reinforcing the synced nature of menus), or focus on a single location by default? There is reasoned disagreement on this point and it warrants empirical exploration.
- Preview frame behaviour on edit — when a change is made in the editable list view, does the preview update live across all visible locations simultaneously? Or does it update the focused location only? The right answer likely depends on how the question above is resolved.
- Popover mechanics at scale — how does the popover approach behave when a menu has many items or deeply nested structure? This needs to be stress-tested in code.
User Stories
As a site owner, I want to manage and make simple edits to my navigation menu without having to use the navigation block in the canvas.
As a site owner, I want to see at a glance which of my navigation menus are currently in use on my site, so that I can quickly distinguish between active menus and ones that are unused or in preparation.
As a site owner, I want to see which navigation menus are active on my site and where they appear, so that I can quickly find the right menu to edit without guessing.
As a site owner, I want to understand how my navigation menu looks in context before I edit it, so that I can make changes with confidence.
As a site owner managing multiple menus, I want to see meaningful information about each one — such as where it's used — so that I can distinguish between them and understand the impact of any changes I make.
As a site owner, I want a clear path from the Navigation sidebar to editing a menu in its actual template context, so that I can make styling or layout changes that go beyond managing the menu's content.
As a site owner, I want to build and populate a navigation menu before it is live anywhere on my site, so that I can prepare it in advance without it affecting visitors.
Visuals
The following are lifted from @fcoveram's comments below
Related Efforts
- A solid routing foundation for the site editor + Extensibility. #70862 — Extensible Site Editor (routing foundation and extensibility tracking issue). This work is built on top of the route-based architecture introduced here and will be delivered under the same experiment flag.
- Include a page selector in the site preview to enhance the UX of global style #72497 — Page selector in the site preview (Page vs Template toggle). The interaction model for switching between contexts in the preview frame draws directly on the design explored in this issue.
Activity
[-]Navigation Sidebar: Rethink as a discovery and navigation surface[/-][+]Navigation Sidebar as a discovery and navigation surface[/+]fabiankaegy commentedon Mar 2, 2026
Thanks for compiling this new issue :)
I will add one thing here which is that I believe we should not just focus on the "Site owner" persona but also consider how we can make it possible for non site owners to ne able to edit the content of navigation menus without needing access to the site editor.
More granular control over roles when it comes to navigation menus is something that would make the lives of many teams a lot easier.
getdave commentedon Mar 2, 2026
Thanks for the feedback. This sounds like a totally valid use case. I assume this would also apply to other aspects of Site Editing as well?
I'm trying to get a handle on the scope of your suggestion as the aim in this Issue is to focus on upgrading and enhancing the existing experience.
fabiankaegy commentedon Mar 2, 2026
@getdave Yeah I think it would be something that probably affects more areas of the site editor. The largest use case from my POV is menu management. But you are probably right that it is a more generalized ask
getdave commentedon Mar 2, 2026
The point is well made though. Maybe you should consider raising a wider Issue as I imagine others have that requirement.
If you enable the
Extensible Site Editorexperiment you can see how the UI is evolving. Maybe there's scope to "expose" certain screens to different roles/capabilities?fcoveram commentedon Mar 3, 2026
Here is an idea that taps into previous conversations and other updates. Below the image you can see thoughts around the flow.
And some notes on the higher-impact changes.
All of the above is a more ambitious idea that is open to change, and the main goal is to spark conversation and connect the dots of other words happening in parallel. The complexity of all these changes is definitely beyond my expertise, but below I’ve made a version that feels more in line with what’s possible today and that could serve as a first step toward an ideal scenario.
What do you think of this?
jameskoster commentedon Mar 4, 2026
I think there's a great opportunity here to reuse (and continue iterating on) the designs we worked on in #72497. Allowing the user to select which page is previewed in the Styles section is basically the same workflow as allowing the user to select which template part is previewed in the navigation section. I also like that this would maintain the 'full screen preview' frame purpose. The column of template parts starts to feel a bit like another DataView...
Instead of the Back
<button I think we should explore breadcrumbs.fabiankaegy commentedon Mar 4, 2026
@fcoveram I like some parts of this a lot. But at the same time I think there are areas that don't really make the experience any easier.
I like that we are using the list view in the "Content Frame"
But I think having a "Drill down" experience there creates a frustrating UX. Instead, I think using the "Sidebar with multiple Content Frames" would make more sense.
That way, you can showcase all of the settings of the selected menu item at the same time as you still see the full hierarchy, etc.
One flow that basically every single site owner goes through at least once is the initial setup of their navigation menu. Where they need to add multiple items in quick succession. And the drilldown just moves you out of that context every single time you try to perform an action.
A long while ago, I also did an exploration of a simplified navigation experience:
CleanShot.2025-02-04.at.16.26.02.mp4
It isn't exactly what I'm suggesting above because I don't think it actually worked too well but still wanted to share it anyways :)
In this exploration I essentially wanted to add a toggle next to the save button where users could switch between editing in the simplified version of edit visually which would render the regular block editor...
jeryj commentedon Mar 5, 2026
@fcoveram Thanks for the design flows!
I like how clicking a navigation doesn't immediately get rid of the other navigation menus. This allows for "hunting" for the right menu without losing context of the other menus. However, I'm worried the small "edit" button will be easy to overlook. I would expect to also have editing immediately available when clicking on a menu item, but I'd hate to lose the fast way of hunting between items.
Do we have a concept of a collapsable main navigation in the admin? I agree with @fabiankaegy that preserving access to the other menus would be really nice at times. Maybe rather than removing the other menus when drilling down we could still show them and collapse the top level navigation like so?
fabiankaegy commentedon Mar 5, 2026
Also I think it's relevant whilst we are talking about this, we should make it a lot easier to add other content types besides pages to the menu. Things like archives and custom post types are really hard to find using the menu appender in the list view.
getdave commentedon Mar 6, 2026
@fcoveram I am AFK but I am just posting to acknowledge your excellent work on the Design/UX side. I will follow up here asap next week.
I would like to add one thing now - @jeryj's early work here (away from Github) was a meaningful input that helped shape the direction this landed on. The synthesis work built on several threads including his, and it's worth flagging that for the full contribution picture.
I agree this is important - thanks for flagging. Do you agree we should address that separately to avoid over complicating this Issue though? You can already add CPTs but I'm sure the UX could do with being improved. Archives are "in the works" but I've never managed to push it over the line. Help on the PR and backports would be very much appreciated 🙇
13 remaining items
getdave commentedon Mar 10, 2026
@fabiankaegy's point is also aligned with the experience we surface in the Editable List View we surface in the Navigation block's inspector controls when editing Navigation block's within template parts. I do wonder whether we should lean into the popover for quick access and then provide a mechanism to "drill down" as a secondary (deprioritised) flow if more detail is required.
What are the benefits of drill down? I'm curious to understand the motivation behind that.
fabiankaegy commentedon Mar 10, 2026
Yeah and maybe just for context. The things that worry me about the drilldown approach is that it adds two additional clicks and a lot of distance to move the cursor to every interaction if you want to edit more than one menu item.
Making changes to multiple items one after another can be done with just one click to change back and fourth with the popover. With the drilldown it means going back to the breadcrumbs or the close button and then opening the next item every time.
fcoveram commentedon Mar 10, 2026
Got it. Thanks @fabiankaegy for the explanation. The reason was mostly keeping content interaction inside the frame area, but I agree with you @getdave that aligning this with the editing interaction in List View in block's inspector. +1 to that.
jameskoster commentedon Mar 10, 2026
I'd be quite wary of introducing different behaviors for desktop and mobile. Especially given the UI is already narrow. The additional maintenance overhead/complexity doesn't seem worth it to me.
jeryj commentedon Mar 10, 2026
@jameskoster
I disagree here. I think the synced nature of menus has historically been very difficult for users to understand. The idea that changing your block in one location and it updates everywhere is very easy to forget. Even if you do understand the synced nature of the navigation, it can be a tedious process to find and check all of the instances that the menu is used to make sure the changes work. Being able to do the work in one spot and see its impact across all its instances before saving is incredibly useful IMO.
For future work, I think the same idea of "show me all the places X is used" is amazing for synced pattern editing. There are plenty of times I've updated a synced pattern and forgotten that it was used in X and the background color change I made doesn't work in that context I forgot about... etc etc. To have one place I can see its impact would save so much time and increase confidence in changes.
Popover vs Drilldown
As I mentioned earlier in on this issue and @getdave and @fabiankaegy reiterated, I strongly feel we should lean into the popover experience from the List View that @talldan introduced. I was on the fence about the popover experience until I started using it. It's so much faster and easier to use with less context switching.
getdave commentedon Mar 11, 2026
Next Steps
Thank you all for the excellent discussion here.
I'm hearing/seeing two points of uncertainty:
My Proposal
I would like to recommend that we move to prototyping the experience in-code.
To be clear, I'm not blocking discussion here but I do think we're at the point where we should bias towards action in order to unblock ourselves.
It's absolutely ok at this point not to have all the answers or the perfect designs. The excellent work already done provides us with enough to get started.
We can address all the outstanding points by experimenting using lo fidelity in-code prototypes (as I referred to in my previous comment). These can explore different options and then these can be demoed and then tested by all contributors and stakeholders (and perhaps even real users?) to help inform how best to move forward.
To that end I have updated the Issue description to reflect the discussion as well as the points of uncertainty that still need resolving.
Hopefully this serves as a point of grounding for the effort and we can now move to exploring how this feels.
fcoveram commentedon Mar 12, 2026
Thanks for summarizing this. I like your idea. Prototyping this will surface the interaction better.
Regarding the two points:
I'm not fully sold in these two points and I'm fine with changing it if research and other implementation in progress require changing the approach.
jeryj commentedon Mar 18, 2026
@scruffian and I worked on a solid start on the prototype over in #76557. We have the editing existing links flow (lots of broken things with actual editing) but it gives the overall structural flow of how it works.
I also explored a little for an alternate view to have a permanent navigation preview in the top area with the templates it's used in underneath. I arrived at this after interacting with the prototype in #76557 for a bit and felt like I was switching between the preview and template views too often, when there was space for both.
Preview of #76557
Screen.Recording.2026-03-18.at.1.28.50.PM.mov
Preview of alt #76645 (rough design)
Screen.Recording.2026-03-18.at.1.19.05.PM.mov
fcoveram commentedon Mar 19, 2026
Interesting. Thanks for working on the preview idea @jeryj
Although I follow the logic of the navigation preview, I'm not sure if it adds value. I would say that it adds an extra layer of complexity when it comes to grasp the purpose of the UI. The frame on the right is a preview container where either a single or multiple previews exist.
The menu structure is already on the left side, so all changes coming from adding, removing, or rearranging items are fully visible as inside a tree layout. Whereas the nav preview on the right only shows the root level items. In addition to this, the style of the frame looks similar to any other preview that takes you to the block editor after clicking on it, but in this case, this is not possible. That might cause confusion as the frame doesn't behave as all the other previews across the admin.
I'm drawn to have the editable list view on the left and the preview container listing all the documents where the menu is used on the right. The left container shows the menu structure with tools to modify it, and the right container shows how the menu looks like in all the places where it's inserted.
Overall, I second the need for previewing the menu, but with the current heuristic, the preview is always an existing document. However, here below I worked on the use case where a menu is created.
Creating a menu
In the current heuristic, the preview frame defaults to render the site homepage and take you to edit it when clicking on it. But when creating a menu inside the navigation section, this preview lacks of meaning as it doesn't show any relevant information regarding the new menu, and instead, it might confuse users.
Because of this, I think we could preview a draft template part that become real after clicking on the "Create template part" button or on the preview area. This flow reuses the current pattern for creating a content type and selecting the template part, and could potentially be used for creating a template when creating a category.
Here below you can see a quick step-by-step flow of this. The last missing steps is landing on the block editor after clicking on "Add" in the Add Template Part modal.
jeryj commentedon Mar 19, 2026
@fcoveram
FWIW, the navigation preview does take you to the block editor for that menu after clicking it.
In theory, I agree with you about using just the template previews to show the updates to the navigation. It was originally my idea even :) However, after interacting with the prototype, I found it to be much nicer to have a large preview of the horizontal layout as well. It could be smaller though. I'm not 100% attached to the idea though. I think it's worth trying out both and seeing how it feels though.
Why not show the large navigation preview if there are no template parts?
Are Add Template Part and Create Template Part the same thing? And should it be "Add to Template Part"?
I think the flow makes more sense as:
fcoveram commentedon Mar 20, 2026
And what document do you edit? The recording from the video in #76557 shows a "navigation menu" document in the block editor's header, but is it possible to insert other blocks and style them?
I noticed that there is a discrepancy between the design and the implementation. In the proposal I shared above, clicking on the select control displays all the documents listed in the preview frame, but in both prototypes, the options/tab show the template part types.
The label I used for the select control is confusing, and perhaps instead of saying "All Template Parts", it should say "All documents". This comes from @getdave's comment suggesting to only list template parts. Unless I understood it wrong. The term "document" is not widely used in the admin, so perhaps another term could work better to refer to these elements.
Creating a menu
Your mental model makes sense, but I'm not sure about how the nav block is added to an existing template part. I guess it is just a block that is added similarly to when you click on "Add after" in the block editor. If so, it could work.
jeryj commentedon Mar 20, 2026
@fcoveram
Yes. It’s the isolated navigation block editor. You can add any blocks that are allowed to be added to a navigation block. I’m not sure a V1 of this project will allow adding all blocks via the list view sidebar, so I think it'll be good to have a way to access the isolated navigation block editor.
Oh - I missed that detail. Thanks for flagging it. Could you link to this design? It doesn't match up with the ones I'm seeing and I'm having a hard time finding it.
Does selecting an option in the drop down make it become full frame within the navigation screen? This drop down could be very large, so it may make finding your template difficult.
Another option is to make a click on one of the data views previews bring that preview full frame but not enter block editing mode until a second click?
I’m not totally convinced of the utility of the single large preview. Most of the time the template will still be pretty small, so it won’t give much better of a preview than the full width data views and will remove all the other templates from view.
getdave commentedon Mar 22, 2026
Thanks for the demo/prototype @jeryj and @scruffian. Some good feedback and discussion here again.
Some thoughts from me below. Overall I would really like to make a big effort to look at this screen from the perspective of a beginner user with little/no experience of WordPress terms. In my opinion we should be looking to:
As things stand I'm not sure we've quite got the balance and we can make this a lot simpler.
I hope it's clear that the feedback below is coming from this place 🙏
Feedback
As I understand it you are referring to a new menu being created - by default it would have no location and thus the site preview is meaningless. In this case we could show the preview of just the Navigation Menu items but I don't think we should be creating a draft template part.
I feel quite strongly that this is not the right mental model and (forgive me) it also sounds like a pretty complicated workflow.
If you create a Navigation Menu you are probably thinking "where can I use this menu on my site?". For example, "how can I add this new menu to my site header"?
This follows the model adopted by the Classic WordPress Menus system whereby the theme registers menu locations and when creating a Menu you assign it to a location.
Applied to the Block Based model (which doesn't have explicit "locations") the presence of the Navigation block implies a possible location slot for a Navigation Menu. Therefore we could find all active template parts (let's avoid the noise of inactive ones) that contain a Navigation block and surface these to the user to allow the menu to be applied to the relevant location.
We should try really hard to surface the most likely template parts first and avoid information overwhelm.
In my opinion the current list of areas shown in the prototype is already too complex for most users. The 80% use case is highly likely to be adding / modifying a menu used in a Header or Footer (there is an argument for Navigation Overlays as the "mobile menu"). Personally I would prefer to see the filters as:
The "More" item would be a fly out menu containing the other "advanced" areas such as "Panel" and even "All Template Parts".
To be clear my motivation here is to simplify the interface and avoid overwhelming users with too much information and power. We can progressively disclosure more advanced functionality.
I'm certainly in favour of avoiding the term "Template Parts". It's a system level concept which we're forcing users to understand. It would be better if we working on the Site Editor could come up with a user-friendly term to act as a proxy for these kinds of reusable global site-wide areas, even if under the hood they are still template parts. Possibly outside the scope of this effort but we could blaze a trail here...
Thanks again for all the work so far 👏
fcoveram commentedon Mar 30, 2026
To @jeryj
I don’t understand the logic of how this content type exists among the other entities, and therefore, the role of the Block editor.
The block editor is for editing documents that stand on their own and can be seen by site visitors on the frontend, or for templates where the block arrangement conditions how the inserted content looks. But in this case, a menu is a tree-structured way to build a navigational element that can only be used via the nav block. In other words, editing a menu is not restricted to a single block arrangement (like a Template), and site visitors cannot visit a menu (like a Page or Post).
From that distinction, editing a menu might confuse users, leading them to believe that the block arrangement they are building exists as an isolated document.
I will add the link in the initial comment.
Yes. We could use the popover element that displays the search input and lists the documents below.
I'm not sure about this.
I think this preview frame as an evolution of the existing one where more layouts are offered, just like in DataViews. The current is a single frame, but with this improvement we’re adding a “cards” one that in the future could also support the “grid” layout.
To @getdave
Thanks for elaborating in the use case.
I agree with the mental model that users have when creating a menu. That said, do you think that it adds value to offer inserting the menu into an existing document or creating a new one after clicking on the “create menu” button? This is the flow where I see that creating a menu requires inserting it somewhere. If you are editing an existing document, creating a menu from the nav block solves this location issue.
I'm thinking of a two-paths flow after creating a menu from the Navigation section:
For the first point, I'm thinking of all the documents as the nav block can be inserted in all of them, not just in Template parts. Although this content type might be the starting point of the implementation.