Repository navigation
Extensible Site Editor: explore direct Appearance entry points with the wp-admin sidebar #83364
Description
What problem does this address?
The Site Editor has management screens for Styles, Templates, Template Parts, Patterns, and Navigation, but reaching them through the main Appearance entry involves switching from the WordPress admin menu into a separate navigation system. This system is hidden behind vague links like "Editor" and "Edit Site" which could really apply to any WordPress admin screen and don't specify that you're entering a separate UI for theme design.
Could these destinations be accessible directly under Appearance, using the normal wp-admin sidebar, while retaining the extensible Site Editor's shared application and routing infrastructure?
Longer-term - could agencies limit access to routes (allowing users to edit Navigation but not Templates, for example) and introduct better governance around the site editor?
site.editor.menu.mp4
I've built a Gutenberg-branch prototype to explore this. The goal is to make the destinations easier to discover and remove the need for a generic Site Editor landing screen—not to replace the extensible editor with five separate applications.
What is your proposed solution?
- Try the prototype in WordPress Playground — no local setup required. Allow the initial WordPress and plugin downloads to finish.
- Prototype source branch.
- Test-only prerelease and compiled plugin ZIP, pinned to commit
9284d2474ef.
The Playground opens a temporary, logged-in WordPress site with Twenty Twenty-Five and the extensible Site Editor experiment enabled. It starts on Styles; use Appearance to switch destinations. Changes are discarded when the Playground is refreshed or closed. This uses WordPress nightly and is intended for prototype testing, not production.
The prototype:
- Adds Appearance entries for Styles, Templates, Template Parts, Patterns, and Navigation, subject to theme support.
- Uses one shared wp-admin host with client-side routes. Moving between these entries stays within the same mounted application.
- Keeps the normal admin sidebar visible on management screens. Pages remains accessible through the existing top-level Pages menu rather than adding another Appearance entry.
- Supports the standard Fullscreen mode toggle when an editable entity is opened in the block editor. Returning to a management screen restores the admin sidebar. Currently full screen mode can not be disabled when editing site editor entities, but could/should be.
- Adds a Patterns list layout with a larger preview alongside the list, including previews for patterns that aren't editable. Currently there's no way to preview patterns in the site editor without editing them directly.
These are bundled in the prototype to demonstrate the experience, but they don't need to ship together. The prototype is not merge-ready; the integration gaps below still need addressing.
Relationship to existing work
This builds on the routing direction in #70862, particularly the explanation that the same route can render fullscreen or inside wp-admin. The supporting infrastructure already exists:
- Routing: Allow plugins to register custom site editor like pages #73120 added page/route registration and cross-plugin extensibility.
- Routing Infrastructure: Allow single routes to be added to WP-Admin separately #73137 added
initSinglePage()and rendering within the normal wp-admin interface. - Boot: run page
initmodules ininitSinglePage#79394 made embedded pages run page-level initialization modules.
There is also precedent for route-specific Appearance links in #61080, which linked Appearance → Patterns to the Site Editor for classic themes.
The broader layout discussions in #72135 and #70913 are relevant to keeping management content and contextual previews independent of the surrounding navigation.
Questions for design and architecture feedback
- Is using the normal Appearance menu for these destinations a direction worth exploring within the v2 experiment?
- Should a generic editor URL open Styles, preserve the current landing screen, or resolve elsewhere?
- Where should Identity controls and extension-added destinations appear without the editor's current sidebar? Is there a valid justification for having duplicate settings screen with only a subset of options, rather than improving the core settings screens for all users?
- Does this align with the feature-parity and stabilization work in Extensible Site Editor: Tracking issue #79895, rather than expanding that release's scope by default?
Activity
fabiankaegy commentedon Sep 22, 2026
Thank you for creating this issue Brian :) I’m in full support of this direction.
I think until we get to the point (if we even ever get there) of the fully JS powered router with the new frame, I think this is the more sensible path to integrating all of this into the admin we have today.
giannisgx89 commentedon Sep 22, 2026
I love this so much!
w3guy commentedon Sep 22, 2026
+1 for this
unscripted commentedon Sep 22, 2026
I agree with this approach. It feels more intuitive and reduces the number of clicks to get to these specific routes. Thanks for putting this together!
For your questions:
youknowriad commentedon Sep 23, 2026
I considered this as well. We should either embrace this or the full redesign at some point.
Question though: What should happen when you navigate from say a "template" and click "edit" on a template part. Should you navigate seamlessly like today (no page refresh) which I guess means you need to find a way to highlight the new menu item on a php rendered html (hacky) or should you reload the page entirely which means you lose the seamless multi-entity editing capabilities and you get annoying "leaving the page without saving" messages non stop.
cc @ellatrix as this is actually something we've been discussing very recently.
bacoords commentedon Sep 23, 2026
Good question. To make sure I understand - when moving from a template part to a template, where am I in the admin?
Rather than compare to the ideal scenario, we should compare to Gutenberg today. Currently when editing a template and moving into a template part, you get two "back" icons on the toolbar, one (to the far left) would take you to the template parts screen, because it's not really 'back' as it is moving you up to the parent post type. The back icon in the center of the toolbar takes you back to the template you were editing.
So the real question is - what is the actual heirarchy of my location right now? Am I still inside of templates or template parts? If I focus in on a template part or pattern while editing some other content type, am I in a new context or just more narrowly focused on this entity temporarily?
I bring this up because there's already not a good answer currently in what we actually have in front of users. So tradeoffs tend to happen, and if so, we should lean towards trade-offs that preference the user experience over ideal architecture.
My response would be that either one (updating the active menu item or leaving it as is) is probably fine rather than wait for "the full redesign at some point".
We could add a bridge between the classic WordPress menu and the site editor. I guess it is hacky to manipulate the DOM with JS, but we could probably find a good way to do it. I think rebuilding the admin nav in React is probably a much harder path considering BC and the vast plugin ecosystem. Or at least this could be a temporary approach.
In either case - I do think the ultimate goal should be that once inside the site editing SPA, we should try to maintain that single instance and avoid full page reloads. But also understanding that most of the WordPress admin our users experience today and for the foreseeable future don't happen there.
youknowriad commentedon Sep 24, 2026
In terms of "urls" at least, currently you move to "template parts"
Bovelett commentedon Sep 25, 2026
I big +1 for this!
jameskoster commentedon Sep 25, 2026
Agreed, and I think it would help to see them side by side. So I mocked up the other one: a full admin shell, with the navigation included, rather than Site Editor routes mounted inside the menu we have today.
Prototype: https://wp-admin-shell.view.fast/
Recording_25_09_2026_12_26_58_optimised.mp4
It’s a workflow prototype more than a visual design proposal. But screens are built from existing WPDS components and patterns wherever possible, so the look is roughly what we might expect. The navigation sidebar is the exception; there isn’t a WPDS equivalent yet, so that piece is custom, and based on many past explorations.
What I tried to cover, while keeping the familiar menu model (including plugin items) as intact as possible:
Plenty still to unpack, and I’m not suggesting this should replace the approach proposed in this issue. Mostly hoping it’s a concrete thing to set next to that proposal when we talk about the tradeoffs.