The site editing experience continues to evolve in WordPress with the introduction of new tools like block locking, toolbar absorption, zooming, new navigation paradigms, browse mode and more. It’s an exciting time but its also adding a tonne of complexity on top of what is already a complex mix of experiences. It’s time we look at simplifying our mental models and establishing a stronger foundation for these concepts to thrive on.

A lot of the feedback we are seeing surrounding FSE and its individual concepts is related to two main issues; too many block types and diverging editors.

What you see here is a proposed plan to tackle these two issues via two main unification tracks. Most of, if not all, the work suggested here has been discussed in one way or another in the past, so this is really just gluing it all together. It should also align with the overall vision of a more seamless editor <> admin experience.

What we are working towards

Before diving into the details, here's a broad strokes (you can ignore UI details) walkthrough of what we are working towards.

full-walkthrough-compress.mp4

Breakdown of work

Track 1: Editor Unification

When should I use the post editor vs FSE editor? You can modify content (e.g. home) in both editors, you can also modify templates in both editors. This is creating confusion and a hazy idea of how things work. The plan below iterates towards the merging of the two editors into one site editing/browsing paradigm, including a dedicated and deliberate space for editing global elements in isolation.

Milestones:

1. Clarifying global elements

We’ve seen plenty of feedback, particularly within the low tech segments, that suggests there is still confusion when mixing global elements (e.g. templates, template parts, re-usable blocks) with local. We need to ensure that people first understand the concept of global elements, and that these blocks are clearly identifiable while editing. Editing across these scopes needs to be fluid but there also has to be clear separation.

Tasks

• Global colorisation and labels
• Explicit edit action e.g. double clicking
• Surface where global blocks are being used
• New user educational content

2. Content first in FSE

content-first.mp4

Once we are confident that people understand global elements, we can now change “site editor” so that it is content first as opposed to template first. Upon entering the site editor you see your home page, including the surrounding template as you currently do, however the page now becomes the focus of the editor as opposed to the template (e.g. editor title shows page, page settings in inspector vs template). This is similar to the current template editing experience within the post/page editor. The template can still be edited in isolation via the templates menu in the left sidebar, or via the post/page inspector as you currently do when in the post editor.

As part of this milestone we will also want to introduce a way to navigate between pages. There are a few approaches to this including browse mode which is a milestone further down, as well as introducing navigation menu’s into the sidebar, but I’d like to first propose the idea of bringing in what is essentially a minified version of the post/page list within wp-admin that allows you to quickly search for and browse to any content on your site for editing. This also sets to stage for closing the gap between wp-admin and the editor.

Tasks

• Editor is content first
• Browse content in sidebar

3. Toggle template

toggle-template.mp4

We’re now at a point where someone can edit their entire “site” (that includes content) via the “site” editor. However, when editing content you don’t always want to see that content in the context of the surrounding template, this is prudent for posts in particular. This is when we introduce the template toggle that gives the user the ability to quickly switch between focusing on their content vs fine tuning the surrounding context. If someone enters the editor to edit a post, it would be disabled by default.

4. Library in FSE

library.mp4

Since we are now content first we need to ensure there are clear pathways to editing global elements beyond an edit action on the selected template in the post/page inspector. Let’s take the existing templates and template parts menu items in the sidebar and group under a Library/Global parent menu. This is a dedicated space for all things global and gives users the ability to edit global elements in isolation. At this point we can also bring reusable blocks into space as well as patterns. See the block unification section below for ideas on how to simplify this.

Tasks

• Parent Library/Global sidebar page to contain templates and template parts
• Introduce re-usable blocks into this space
• Introduce patterns into this space

5. Browse mode

browse.mp4

Browse mode gives people a way to navigate through their site in a similar fashion as their users whilst offering pathways into editing their site as they come across needed changes. When the sidebar is open, the user is prompted to save and we enter browse mode. Navigating through the content experience we built in the sidebar as part of milestone 2 also updates the “browser”. The site editor has now become a more contextual viewing and editing experience.

6. Menu’s in sidebar

The left sidebar is starting to take shape and is becoming a core part of the WordPress experience. It’s given us a natural space for other global actions to live such as menu editing and global styles. For this milestone we’ll move the current navigation menus panel into the left sidebar.

7. Global styles in sidebar

With browse mode in place we can also move global styles into the left sidebar so that you can browse your site as you’re making style changes globally. We can move to a “push to library/global” paradigm to still enable editing global styles locally as you come across needed changes.

Tasks

• Move global styles to sidebar
• “Push to library/global” on primitive blocks.

8. Post/pages link to FSE

At this point the editors are essentially merged, and we can now link posts/pages from admin off to this new experience and deprecate the old one.

9. Zoom

toggle-template.mp4

Now that we have a unified editing experience we can introduce settings such as Zoom that can be used no matter what you’re editing. The editor is becoming a single flexible workspace that can be organised and shaped depending on what task you’re trying to accomplish.

Track 2: Block unification

Blocks, templates, template parts, re-usable blocks, patterns, sections, elements 😰 It’s a lot for anyone to take in let alone site editors who are new to WordPress. We can draw inspiration from existing design tools such as Figma, or even Webflow, that are arguably far more capable and yet offer a much simplify component/symbol model.

This proposed plan stems from [this thread](#34352) and specifically [this comment](#34352 (comment)). To summarise, we should look at consolidating our different block types into a single concept (e.g. patterns or just blocks) that can be configured in many ways. We can also make use of the Library concept outlined in milestone 4 of the editor unification track above.

Milestones:

1. Block merging

For this milestone, template parts, re-usable blocks and patterns are all merged into a single concept (e.g. patterns or blocks) via synchronisation and semantic categorisation, and therefore behave in the same way as outlined in “clarifying global elements” milestone above. Patterns are synchronised by default but can be detached to individual blocks. The library now just shows templates, patterns and potentially core blocks for styling.

2. Block inserter

inserter.mp4

With a simpler block model in place we’ll have a much easier time designing new experiences and updating existing ones. The block inserter becomes a way to quickly access blocks and patterns from your library, with equal emphasis on both. It also provides a pathway into editing these global blocks in isolation via the library.

3. Pattern schema

Connecting patterns to standard schema’s not only means a more predictable experience when switching patterns on your site, but also positions Gutenberg as the standard way block content should be structured.

4. Pattern overrides

There are many times when you need a pattern to remain in sync with how it’s presented globally, but you want to override the content within. Pattern overrides let you define which attributes of a pattern’s inner blocks can be replaced whilst keeping the maintainability benefits of synchronisation. With Pattern schemas in place, any attributes that are mapped to schema properties would be overridable by default. Place a “Recipe” pattern in a post, override its title, ingredients etc, and know that you can update the pattern design without losing the instances of the Recipe. The same concept can be applied to custom post types and templates.