TLDR WordPress has two block editors: the post editor that allows you to edit posts and pages and the site editor that allows you to edit templates, headers footers… Converging the post and site editors has been a difficult task, but we’ve completed it; read on to know the context, process, and consequences.
A brief history of the post and site editors
At the start of the Gutenberg phase 2 in WordPress, we needed a safe space to iterate on the site editor. Explore things like template editing, patterns, design modes, focusing on template parts, zooming-out… We decided to create a new package and a new page in WP-Admin which became today the site editor. The dichotomy was clear:
- The site editor was the place where you would edit templates and template parts.
- The site editor had different modes: showing outlines, focusing on specific parts of the template (headers, footers).
- The site editor allows rendering both templates and a page within these templates.
- The site editor allows switching between entities, and editing multiple entities at the same time.
- The post editor would remain as an editor to edit post or pages (or custom post types) in isolation.
That meant that over time, we had to duplicate a lot of code from the post editor into the site editor, things like: headers, preferences, sidebar panels, device previews…
As we iterated in Phase 2, the post editor started gaining more features that were initially only meant for the site editor. We first enabled access to block templates in the post editor. With it came the multi-entities capabilities, access to template parts, focus modes…
The site editor also saw the introduction of page editing capabilities. Also, the separation between “editing entities” and “navigating between entities” became clearer over time. We have a site editor “shell” to navigate entities, and we enter a focused editor to edit these entities.
Converging
This meant that both the site and the post editor gained the exact same capabilities but as the code bases were separate, and because of the organic nature of the iterations that happened to the code over time, they diverged slightly. Some panels looked different, some shortcuts were taken…
Users and contributors start to notice these small difference and different issues have been raised to close these gaps. James Koster opened this issue meant initially as a way to close the gap in terms of sidebar panels.
In parallel, our roadmap included things like:
- Building DataViews for the different entities
- Replace the posts WP-Admin entry with a site-editor like experience that relied on DataViews.
- Expose the same extensibility capabilities the post editor offers in the site editor.
We had a great opportunity to start coalescing the code-bases while iterating on these roadmap tasks. Continuing on the previous path (separate code bases) was certainly possible but we’d be pushing ourselves even more in a situation where gaps keeps increasing between both editors.
Conceptually, the idea was simple: The frame (also referred to as canvas) of the site editor is basically just the same thing as the post editor for a given entity. We can think about it as a single component:
<Editor postType={ postType } postId={ postId } />A plan has been shared but to achieve that based on two very divergent code-bases meant:
- Aligning state.
- Aligning UI components.
- Aligning user preferences.
- Aligning extensibility APIs.
All of that while:
- Teams are constantly iterating on new features.
- Preserving backward compatibility.
As the creed says, we’re in a marathon, not a sprint, so, 88 PRs and 2 WP releases later, the @wordpress/editor abstraction can be considered complete. This convergence also means:
- +12027 / -18817 We have 6790 less LoC to maintain.
- Teams can implement editor features in a single place and have them available in both post and site editors.
- Plugin authors can extend the editor once and their extensions work in both editors at the same time.
- We’re in a better position to explore replacing the posts and pages WP Admin menu items (or any custom post type UI) with a DataViews based experience while maintaining strong compatibility and features with the existing pages.