The great unification

[SaxonF]

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.

[annezazu]

Thanks so much for this excellent and thorough exploration. In particular, it really helps to have both shorter videos and a longer one to get a sense of what's being thought of. At a high level, I see so much promise in what's here based on feedback that's come in from the outreach program over the last few years. In particular:

• Clearer distinctions between global vs local elements, with great prompts.
• Improved information architecture for things like Global Styles.
• Browse mode to more readily and smoothly move amongst your site and see changes (huge for Styles).
• Deeper connection between posts/pages <> templates with improved clarity around when you're editing each.
• Greater understanding of where things are in use.
• More entry points to the experience.

My concerns lie with the layer below this effort with the settings for blocks feeling inconsistent, + button everywhere, when you can edit vs when you can’t/how to make that clear, what the experience looks like for those with less access/permissions, how best to clarity in the UI when to use which item (reusable block, pattern, template part), how best to apply a template/see it in action especially for templates like Author, etc.

P.S. I’d love to see the title updated to something more descriptive of what you’re trying to accomplish so folks find it.

[mtias]

Thank you for the effort in piecing all the things together from a design perspective! It's always a crucial exercise to do given we are building from the bottom up and the overarching flows can become harder to grasp at times. Stepping back and seeing the experience as a flow and not distinct features is a fundamental aid.

I think the order as presented here is not entirely viable. It jumps ahead too far while there are still unresolved issues to reconcile.

---

Clarifying global elements

I like some of the suggestions. The "global" symbol used for templates parts and reusable blocks has been good, but we haven't made much progress in the coloring and click to edit flows.

I'd like to see some work done on the block inspector to show / describe that a block is synchronized. That's something we can introduce immediately to reusable blocks and template parts.

The use of more contextual help in general can help reinforce some of the most difficult concepts like global / local.

---

Content first in FSE

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 used to be implemented almost fully fledged in earlier versions of the site editor. Check out this older pull request:

• Edit Site: Implement post switcher and integrate with "navigate to link". #22543

One of the problems was it created confusion over whether you'd access a post from Admin > Posts or from Admin > Site Editor > Content > Posts. These are not equivalent pathways, and is not trivial to solve because the post editor is a different environment than the site editor with a local post loaded, particularly when it comes to plugin or meta extensions running. This has to be accounted for because toggling the template editor from Admin > Posts would be a different environment than in Admin > Site Editor > Templates > Single today. The list of smaller details can get tricky and increases in complexity when handling roles — the obvious one is an author that cannot edit a template and thus cannot access the site editor.

There are also technical challenges like the post-editor migrating to using iframes that stand in the way. All in all, to make content / template share the same framework there needs to be a lot more steps in the middle and a more in depth dive into the implications.

---

Library in FSE

I'm not sure how clear or discoverable bundling templates and patterns in the "library" would be. Also, a separate "design" entry for global styles creates some dissonance with the fact that patterns are also inherently about design. It's not straightforward to me what are the semantic groupings. For example, if the impetus is to keep them separate, a name of "styles" seems better than "design" in that specific case. Would block management (installing, disabling, etc) exist at this level or separately?

I'd be curious to see a workflow around managing and creating patterns extracted from this first.

---

Block Unification

I don't think the tools cited are more capable when it comes to content management, which is the fundamental reason why the model is not just blocks and patterns at a deeper level. There's a need for semantic representations that are not merely taxonomical, including permission handling, operational flows that require entities to be discriminated even if their representation is equivalent (blocks and patterns).

This has implications on where and how they are accessed, not just by the WordPress UI but by any plugin and workflows. For example, an editor might have access to all reusable blocks created as content but not to template parts or patterns. We can them all the same, but then the places where people can access them have to be clear in their own right. It is important to understand that under the hood they exist as separate and distinct entities, with separate and distinct behaviours to account for.

[SaxonF]

Thanks for taking the time to read through and provide feedback @mtias !

I think the order as presented here is not entirely viable. It jumps ahead too far while there are still unresolved issues to reconcile.

What I've tried to convey here is how a user would experience the transition, rather than technical tasks. I'd be happy to expand on this proposal to handle any additional user needs and pain points that aren't covered.

I'd like to see some work done on the block inspector to show / describe that a block is synchronized.

Definitely something we can look into beyond the consistent styling of global icons. One idea outlined above is to show where the global element is in use and provide shortcuts into editing in isolation.

One of the problems was it created confusion over whether you'd access a post from Admin > Posts or from Admin > Site Editor > Content > Posts.

I can understand this perspective but I also think the editor workspace is separate enough that it shouldn't be a major concern. As we've discussed in other places there are other ways of navigating through a site when in the browser/editor worth exploring, but they would also run into this challenge. Part of the reasoning behind this is that it also acts a stepping stone towards the grander vision of admin.

This has to be accounted for because toggling the template editor from Admin > Posts would be a different environment than in Admin > Site Editor > Templates > Single today. The list of smaller details can get tricky and increases in complexity when handling roles — the obvious one is an author that cannot edit a template and thus cannot access the site editor.

From a users perspective, are there more reasons why they need to be different environments? I expand on this below but from a permissions standpoint templates could be locked down in a similar way to other blocks/patterns. In this way editors could see the surrounding context of their page/post but would not be able to edit it, which offers advantages over not being able to access the site editor at all.

For example, if the impetus is to keep them separate, a name of "styles" seems better than "design" in that specific case. Would block management (installing, disabling, etc) exist at this level or separately?

I would actually like to see block styles pulled out of global styles and moved into the same space as patterns and templates. Blocks management (installing, disabling etc) would work the same way as patterns. Block style variations (in future even pattern style variations) could also be created and styled here. I agree a more specific label like "Styles" makes more sense than "Design" if that were the case. Styles would remain focused on the foundational tokens that make up the character of your site and blocks.

There's a need for semantic representations that are not merely taxonomical, including permission handling, operational flows that require entities to be discriminated even if their representation is equivalent (blocks and patterns).

Could you expand on this a little bit? What other behaviours do we need to account for? Disregarding the technical side of things, it would be worth exploring whether these user needs could be catered to in a unified world as its a much easier model to understand.

My thoughts are that if we had a single concept of a block or pattern, we would build out functionality in a more modular and re-usable manner. To use your permissions example, we could extend the existing idea of block locking to cater to specific role constraints in enterprise use cases. e.g. maybe editors can place core blocks like buttons, but cannot style them. Maybe certain patterns (e.g. a header pattern) should be locked down but not others. Templates could also be locked down using the same UX patterns as blocks. Functionality would be moved to be per block rather than the type of block. This feels a lot more flexible to me than treating block types uniquely.

[mtias]

I can understand this perspective but I also think the editor workspace is separate enough that it shouldn't be a major concern.

I used to agree (as shown in the older implementation where pages and post content was front and center). It's something that was pending to be revisited, though. The main hurdle was getting some of the core site editor interactions in a better place — including the multi-entity saving flow, which wasn't as robust or refined when we first allowed content editing. All in all, things are in a much better place, so it could be surfaced again with care.

From a users perspective, are there more reasons why they need to be different environments?

Fundamentally, no, but the technical issues are quite a few which means we still need the direct entry point for author flows, which today also means separate editor packages. The situation with plugins directly targeting post context is also not solved. Reconciling packages is not that straightforward so we cannot assume the site editor can just absorb it all.

In this way editors could see the surrounding context of their page/post but would not be able to edit it, which offers advantages over not being able to access the site editor at all.

Many blocks won't allow even displaying the surrounding information without editing permissions. There are many issues that describe that specific problem separately (view context for admin/editor level blocks) to account for.

Disregarding the technical side of things, it would be worth exploring whether these user needs could be catered to in a unified world as its a much easier model to understand.

The way I see it there are three layers we need to account for and we cannot disregard them: a technical one (how things work); a conceptual one (how things are represented); and an experience one (how interaction occurs). Your proposal mostly focuses on the latter from a user perspective, which is great. What I'm highlighting is that we cannot divorce the three of them. It's not just a case of normalizing "everything is a block" because that statement means different things at all three layers. We can say "everything gets to be experienced as a block", and we could even say "conceptually, everything gets to be represented as a block" but we cannot say "all blocks are indistinct in the database" because we need models that allows the system (and plugins, etc) to interact with the various entities and workflows in concrete ways. Theme switching flows need to know how to operate on template parts but not on reusable blocks, so they need an expression that is not just a meta value of a block that says it's a synced block. Permissions, bulk editing, etc, also benefit from type separation where you can make assumptions on the properties of elements just based on how and where they are saved.

This doesn't assume type separations need to be exposed as terminology and jargon to the user, but it also cannot disregard it, because when the user marks a block as "synced" we need to know the context they are operating at to know what the semantic instruction ought to be. Otherwise we need to ask the user, which brings back the need to expose the conceptual layer. There's a myriad of things where knowing the semantic value of these "blocks" comes into play: caching mechanisms can ensure template parts get separate caching buckets from dynamic pages and queries so they don't need to be purged as often; workflows can ensure different sets of validation for different types; etc.

This doesn't make things more or less modular — blocks fundamentally work the same way and use the same APIs. The functionality of blocks is the same, but an external actor needs to be able to act on them without having to interpret and filter their semantics.

[SaxonF]

Your proposal mostly focuses on the latter from a user perspective, which is great. What I'm highlighting is that we cannot divorce the three of them. It's not just a case of normalizing "everything is a block" because that statement means different things at all three layers. We can say "everything gets to be experienced as a block", and we could even say "conceptually, everything gets to be represented as a block" but we cannot say "all blocks are indistinct in the database"

That's fine. I'm naive to a lot of that complexity but I'm also suggesting the end user should be too, regardless of how things work behind the scenes. We should be designing experiences in a way that can be applied to any block type to minimise the number of interactions and models they have to learn. e.g. header template parts could just sit within a header pattern category in the inserter, as can re-usable blocks. We don't necessarily have to call them template parts as you suggest. Similarly editing/locking/styling/etc template parts/blocks/patterns/templates should behave the same way. I see similarities with Segment's semantic events. e.g. When creating a pattern you could choose which category to save them in, and some categories we recognise semantically. This also relates to the block schema discussion.

I miss be misunderstanding your point and if that's the case I apologise!

[mtias]

We can do a lot in the UI to reconcile experiences and erode differences that get in the way of the ease of use. For example, connecting patterns and template parts more is an obvious one. We might be able to completely de-emphasize the "template-part" name from any user-facing interface in favor of synced patterns (or however we want to express that).

My point is that we need to reason about whether a synced pattern is a template part internally always or if there are cases where a saved pattern is a reusable block (content driven, saved separately in wp_block, different sets of permissions) even if we are presenting it as a synced pattern again in the interface. We cannot fuse them entirely in their representation because an author should not have access to inserting the "synced pattern that is the site header" but they should be able to find and insert the "synced pattern that is a customer testimonial".

[gziolo]

Track 2: Block unification

I can share my experience concerning block unification based on the challenges with the current workflows I discovered when preparing for my WC EU talk Level Up Block Building Skills. I included a few demos in my slides that I'd like to share first to set the proper context.

Inserting Block Patterns

Block.Patterns.mov

Creating Reusable Block and inserting in other places

Reusable.Blocks.Screencast.1.mov

Inserting Template Part block and choosing from Block Pattern

Template.Parts.Screencast.1.mov

Inserting Template Part block and starting blank

Template.Parts.Screencast.2.mov

---

The recommendation is to use Template Parts and Reusable Blocks for things you want to have in sync with each other, whereas Block Patterns are best for content you expect to change across your site. In practice, it's tough to explain how all those concepts differ. The best way to illustrate is by checking official learning materials:

• The Difference Between Reusable Blocks, Block Patterns, Templates & Template Parts
• Comparing Patterns, Template Parts, and Reusable Blocks.

---

Some of my observations:

• Block Patterns have the best flow at the moment and excellent integration with the inserter, giving users many options to discover what they need.
• The concept of Reusable Block is completely hidden on the site until you manage to create your first block. Once you have created reusable blocks, they have a prominent place in the inserter. However, the list of reusable blocks isn't integrated with the sidebar in the (Site) Editor.
• Template Part is exposed as a regular block in the inserter with the Header and Footer variations which is nice. However, the process of inserting the saved template part isn't intuitive. You need to insert a Template Part block first and choose it from the list of options. The nice part about template parts is that they have a prominent position in the sidebar of the (Site) Editor.

---

I definitely want to echo that the technical difference between those 3 concepts are very important and we need to retain their characteristics. However, it's becoming more prominent that we need to make those experiences easier to discover and use. It's something I discussed with many folks after my talk at WC EU and there was a common agreement on exploring the following ideas:

• similar to what is discussed above, the Reusable Block and Template Part blocks could have some visual indicator explaining that they stay in sync and are globally managed
• Template Part and Reusable block could be better surfaced in the editor, in a more unified fashion, in effect
  • all saved blocks on the site should be exposed in the inserter, not only Reusable
  • not only Template Part blocks, but also Reusable blocks could be listed in the sidebar of the (Site) Editor

[luisherranz]

Thanks for this interesting proposal, Saxon. As a believer that designs tend to drift apart as they progress, I'm in favor of any attempt at design consolidation to simplify the mental model. I think that time spent asking these types of questions is time well spent and a healthy exercise in the long run, even if not everything can be simplified/consolidated at the end 🙂

I'm also glad to hear from Matías' comments that some unification on the UX side is possible. I don't feel I can contribute much to the UX aspect since it's not my expertise, but I personally like pretty much everything about Saxon's proposal.

However, I'm afraid that if we don't change the underlying implementation as well as the UI, we could end up making everything very confusing for the developers, so I hope we can avoid that.

---

In terms of implementation, if we were to consolidate the different groups of blocks into a single one, I guess we would need to:

• Consolidate wp_template_part and wp_block (reusable blocks) post types into wp_pattern.
• Consolidate the /patterns and /template-parts folders of themes and plugins into /patterns.

Technically speaking, templates and posts are also groups of blocks, but their separation seems more justified as they clearly represent the layout and content of each URL.

If I understood Matías correctly, it seems like the different groups of blocks were implemented as different post-types to:

• Be able to do separate database queries for each type (semantic filtering).
• Let people set different user permissions for each type.

@mtias, please let me know if I'm missing other implementation considerations.

Some ideas:

1. Semantic filtering

   One path forward could be to use taxonomies to define what is currently defined as post-types. It could have other benefits:

   • Post-types are exclusive from each other, whereas multiple taxonomies can be used simultaneously.
   • Other minor categorizations (like area or blockType) could be consolidated using additional taxonomies.

2. User permissions

   Post-type permissions let people set different permissions per each group-of-blocks category, but I wonder if those post-type permissions are enough for what we people need to accomplish in complex scenarios.

   So the questions could be:

   • Are post-type permission enough or do we need a new permission system for block/patterns? (actually, the current post-type permission system seems to fall short for templates).
   • What granularity of user permission do we want to allow? From editing posts, templates, and patterns, to modifying whole (or part) of the global styles and its derivates (like the template or section styles/setting) and finally blocks: adding, removing, and reordering, but also block supports, presets and potentially other attributes.
   • And finally, could a new permission system for block/patterns like that support the pattern consolidation proposed here?