Repository navigation
A simpler editor header for document identity and actions #83102
Description
With pattern editing now part of the default experience and the admin bar always visible, I’ve been exploring ways to simplify the editor’s header by enhancing some elements and removing others that can be accessed elsewhere.
This is not a redesign of the header, but a fresh perspective on the document bar section that removes visual information while supporting the existing complexity. Before detailing the proposed changes, here is the design.
CleanShot.2026-09-17.at.17.38.21.mp4
Document area for identity and actions
Now that the admin bar is present in the editor, the document bar no longer needs to trigger the command palette. Instead, this area can display the document identity and trigger related actions.
Those actions are placed next to the document name to follow a common pattern. This doesn’t replace what the inspector offers and it makes them more contextually relevant as the header serves this document’s purpose.
Back button in browser
Now that the chevron action exits the editor, having two back actions seems like an inelegant way to navigate between documents. Since the browser’s back action triggers the same function during editing, removing it simplifies the process while preserving full functionality.
Show template by default and hide the symbol
The layout icon simply indicates when the template is visible. Since Canvas is where the template content appears, removing the icon seems necessary. Additionally, displaying the template by default creates a more consistent experience, as the content on the canvas closely mirrors what will appear on the frontend.
Entity type as a symbol, not a label
The entity type is now represented by a symbol instead of a second label. Currently, editing the “Pages” template displays two nearly identical labels side by side, making it difficult to distinguish from a Page at a glance. A symbol instantly clarifies the difference, and since Styles already pairs an icon with a label to switch between entity types, this approach leverages a familiar screen rather than introducing something new.
Purple for sync content
Following the change above, the icon can carry the purple already visible in the ListView area. This small detail makes it more consistent, and the editor’s header feels more like the document’s main area.
Nested elements as a breadcrumb (#73953)
Editing a nested element, such as a header within a page, follows a design inspired by the new breadcrumb component, where parent elements are button. The nesting leverages the symbolism of the navigation region in the editor’s footer to indicate that an element lives within another.
This concept goes beyond basic pattern editing and feels simple for both single documents and documents with multiple nested elements. Although the design removes elements, it effectively preserves all available actions.
What do you think of this idea? @WordPress/gutenberg-design @WordPress/gutenberg-components @annezazu @talldan @ramonjd
Activity
hanneslsm commentedon Sep 17, 2026
Thanks for working on this. The mockup looks great.
I like all the proposals here, but this idea is my favorite. I always have to tell my clients to activate the template view, which seems unnecessary.
I didn't get the step in the video, where you click in the inspector
Page> TemplatePages. I nearly always need to change the template on new pages (my default is with a page title, but usually I add hero patterns, so I need to switch to the template without a title). I assume you just skipped theedit templateandchange templatemenu in the mockup?Following that, another thing I'm not sure about is placing "Rename" and "Order" in the dropdown. I would really like to see them in the inspector, to be consistent with the Quick edit. See #76076 and #70968
Other than that, I really like the direction!
jasmussen commentedon Sep 18, 2026
Absent any other details from this issue, perhaps this should also be an option in #43583, CC: @jameskoster.
fcoveram commentedon Sep 18, 2026
Yes, sorry. I missed that step 😅
Thanks for adding more context. I think the discussion around actions in the inspector highlights a UX friction that this proposal addresses. Your point on why some actions are behind the ellipsis menu is valid, so perhaps the direction both topics should take involves:
ramonjd commentedon Sep 21, 2026
Thanks for looking at this. I don't have much to add now, other than I think it's a worthy exploration. The document bar is helpful and visible utility, so giving it more contextual actions makes sense.
Would this be for posts/pages in the post editor? If so I'm on the fence about it. I can only draw from personal experience, but the template often gets in the way of writing. If we're just talking about the site editor + pages, then ignore me. 😄
hanneslsm commentedon Sep 21, 2026
I know, I’m going off topic, but I’d like to say this: There’s a difference between building websites with patterns and writing texts.
For the former, it’s essential for a good UX to display the template. For the latter, not so much … but we also have distraction-free mode and spotlight mode, for example, which could be useful here and might currently be underused. (And now we’re back to editing modes again 😆)
Or, to bring the discussion back to the original issue, maybe we could integrate these modes even better into the new header? They're currently hidden in the three dots options menu.
jasmussen commentedon Sep 21, 2026
Exactly right, which is why I think we ultimately need an out of box preferences experience a la #43583. Anecdotally with a datapoint of 1, in nearly all block editors, I have the block toolbar by the block. But for my own site, where I mostly write, I have top toolbar enabled. It's one thing to make it easy to switch and flow between the two, but there's simply some onboarding options worth setting.
fcoveram commentedon Sep 22, 2026
Thanks for chiming in, I second your thoughts.
Regarding the "template on" by default, I'm thinking of pages and posts. A first experience that shows a one-to-one relationship between the editor and the frontend. That should not modify the current settings for the Top toolbar and Distraction free that each user has set.
The modes in header discussion goes beyond this ticket's scope. This one is for document identity and nested elements, rather than actions that modify the editor controls. But I agree we should work on it.
I'm curious about @talldan thoughts as ticket #73953 exists
talldan commentedon Sep 22, 2026
I like it, but I share Ramon's thoughts about enabling 'Show template' by default for posts. I think a lot of users might be confused by it, and for me that change feels like a separate decision anyway. I think the editor header area should work regardless of the default, since different site owners might want to customize it.
There are some details that might need to be decided on, like what happens if the breadcrumbs grow longer than can be shown in the header. On the technical side I'm not sure whether the entire history is available to drive the breadcrumbs, but that's something that could be worked on and checked for feasibility.
fcoveram commentedon Sep 22, 2026
I may be missing context behind the decision, but at first, I don't understand why a page shows the template but not a post. My approach doesn't minimize user preferences and, but for a first-time user, this difference is also cryptic.
Regardless of the above, I agree this is a separate conversation. I will try a new version that shows the template icon so its on/off condition is more explicit.
Perhaps @WordPress/gutenberg-components folks can help us here.
breadcrumbis the inspiration of this work, and the component does solve UX-wise the use case mentioned.paaljoachim commentedon Sep 22, 2026
Just some quick feedback....I really like having a drop down in the middle top to show editing of the title but this drop down seems like a do everything drop down. What about starting much simpler and taking it one step at a time. (Maybe I am not getting it...:)
bacoords commentedon Sep 22, 2026
Great exploration. There's a few things I like about this and a few concerns.
Agree on removing the dual 'back' navigation elements.
Agree on previous comments that an additional dropdown is confusing. I'd rather see the command palette improved, such as offering contextual actions by default, grouping results, etc.
The use of icons to represent content types is very confusing. We see this in the command palette too where it's unclear whether I'm editing "Cart" the page or "Cart" the page template. I would much rather see a content type breadcrumb that can take me back to all of those content types (i.e. Pages > Privacy Policy) which is closer to how users think about their content:
toolbar.demo.mp4
The same goes for the use of the 'template' icon the editor currently adds to that toolbar to convey that the template preview is active. It's undiscoverable and unactionable so I agree with removing it. That said, in this exploration particularly, I like the use of purple to convey global interfaces and would keep that.
annezazu commentedon Sep 23, 2026
My initial thoughts are that this is doing too much and feels like a grab bag of options added in. It doesn't really make sense to me why the options that are in the menu are in there and how we expect users to know or find that this is something they can even click on.
fcoveram commentedon Sep 29, 2026
Compared to the current header, the design proposes two main changes: to show the nested relationship between the document and the inserted patterns, and to move the document menu and other existing actions next to the document name.
For the nested element, the design removes the gray blob and optimizes the titles of the elements involved. Here is how it looks now.
CleanShot.2026-09-29.at.16.15.52.mp4
I wonder if that's an improvement in the command palette rather than continuing to use a label for the content type. The two-label combination only appears in the Editor’s header, while the admin sidebar and ListView show the icon + label structure (for Pages, Patterns, Templates, and all Template Parts). I’m drawn to follow that existing structure rather than rely on a label, since the current “Pages” template is also confusing.
I follow your logic, and I agree with certain parts, but this proposal addresses the current relationship of elements inserted in a document rather than extending the navigation to the admin.
That said, @jameskoster shared an interesting exploration here (#83364) that goes into your suggestion. However, adding the breadcrumb requires revisiting the whole header and accommodating the actions that serve an editor-only purpose. I don’t disagree with the idea, but your comment could benefit the conversation happening there.
Regarding the document menu currently in the inspector, the design addresses the affordance level discussed in #70968, making the title easier to reach than the current “Document-type tab > More menu” path. Instead of moving a single action, it duplicates the whole list plus other document-related actions that might benefit from this quick affordance. But as @paaljoachim said, maybe start simpler and just duplicate the Inspector menu.
After further thought about the conversation on Templates, I agree to follow @talldan and @ramonjd suggestions to keep the feature aside. Nonetheless, the current header shows an indicator (“layout” icon) to indicate whether the template is on or off. To preserve that existing feedback, I think we can show the post type icon when the template is on and hide it when it's off. Something like this.