2021 will be an eventful year for theme developers.
I released a new free WordPress theme last month. It’s called Eksell, and it’s a portfolio theme with a masonry grid on archive pages, category filtration, full color settings, extensive block support, and developer friendly code with CSS variables and more actions and filters than any child theme could reasonably need. I’m pretty happy with it. I’m also pretty sure it will be outdated before the year is over.
Why? Because 2021 will see the introduction of the most significant change to WordPress themes since the modern theme system was released in version 1.5 of WordPress, 16 years ago.
The change I’m talking about is Full Site Editing (FSE), and the new Site Editor. Over the years, WordPress users have had to use multiple different tools and workflows to manage the content, structure and design of their sites. Menus have been managed through the Menu options page, which has a different structure than the Widgets options page, and both are available (although managed differently) in the Customizer, where you can also find all kinds of settings added by themes and plugins – usually built in a way that prevents settings from being carried over from one theme to another. That’s not to mention the entirely custom options pages that the majority of premium themes still use, often stored in dedicated database tables and presented with a design language completely alien to the rest of the administration panel.
WordPress is a mess. We’ve gotten used to that mess since many of us have used it since it looked like this, and since we’ve navigated it daily for years until it’s become second nature to us – but it is still a mess. In comparison, services like Squarespace have gradually improved until they now offer site owners more control over the structure and design of their site than the out-of-box WordPress experience, while still being more user friendly.
Full Site Editing is WordPress answer to that development. It will introduce a new editing experience that will allow you to change not just the structure and content of your site, but also its layouts, colors, typefaces, and more.
We often use Gutenberg as a synonym to the block based content editor introduced in WordPress 5.0, but Gutenberg is more than that. The Gutenberg project encompasses all of WordPress, and aims to extend and streamline the WordPress editing experience across the board. It will make it possible for site owners to take more control over the structure, design and content of their sites. The new content editor was phase one of that project. Full Site Editing is phase two.
Where you use the content editor to edit the content of individual pages and posts, the Site Editor will be used to manage the structure of the site as a whole – what you want to include in the site header, the site footer, the menus, and so on. Areas of WordPress sites that have long been the domain of theme developers will now be opened up to site owners, and if they’ve already taken the Block Editor to heart, the step to working with blocks in the header, footer and other areas of their site will hopefully be a small one.
Raise your hand if you’ve heard this one before: Everything is blocks. Until now, it’s been true for the content in the content editor, and when the Full Site Editing phase of the Gutenberg project is complete, it will be true for everything else on the front-end of WordPress sites as well. At least on sites whose owners choose to make that transition.
A Note on Terminology
Both the Site Editor and the block based content editor edit blocks, so it’s reasonable to ask why many of us still call the content editor the ”Block Editor”. A lot of the terminology is in flux while Full Site Editing is being merged into Core, and it will probably not be fully settled until WordPress 5.8 is out in July or 5.9 is out in December.
The term ”Block Editor” has largely been used to differentiate between the block based content editor introduced in WordPress 5.0 and the old TinyMCE content editor – the Classic Editor. The Classic Editor plugin will no longer be actively supported by the end of this year, so it’s probably time we start calling the default editor the Content Editor and be done with it. Uppercase, because I’m fancy like that.
Full Site Editing will be a big change for WordPress themes, and for the role they play in the larger WordPress ecosystem. If a theme developer wanted to create a site header with the site title, description, main menu and social icons before the Site Editor, you would have to write PHP or JavaScript that generates markup for all those elements. With the Site Editor, you simply define a template part for the site header, with blocks for the site title, description, menu and social icons added by default. The site owner can then edit that template part in the Site Editor and, for example, replace the social icons with a newsletter signup form. He or she could also dump your default header in the trash and build an entirely custom one, with whatever layout, styling and blocks he or she can dream up and build in the Site Editor.
The markup and structural CSS of the blocks are provided by WordPress itself and by block plugins. The theme just needs to supplement them with block styles, default style settings and CSS that adjusts the appearance of the blocks to match the design language in the theme. Having Core generate the markup can be a huge boon for everything from security to performance and accessibility, and by handing markup generation over to Core and to block plugins, themes will differentiate themselves with their design instead of huge lists of theme specific features.
This also means that themes that fully embrace Full Site Editing will become smaller. Much smaller. A good example is Twenty Twenty-One, the WordPress 5.6 default theme, which contains 48 PHP files. Twenty Twenty-One has received a block based sibling in TT1 Blocks, which is built entirely for the new Full Site Editing features. TT1 Blocks contains just five PHP files and seven HTML based block templates. In time, we will likely be able to create WordPress themes without any PHP files at all. At that point, modified themes will also be exportable directly from the WordPress administration panel, so you will be able to create and share themes entirely in the editing interface. No coding knowledge required. Theming, democratized.
That future is still a ways off, of course. Right now, TT1 Blocks can’t recreate all of the functionality in Twenty Twenty-One, because the Site Editor is still very much a work in progress. But it’s easy to imagine where it’s heading. Time that theme developers previously had to spend writing copious amounts of PHP will be spent on building creative layouts and fine-tuning colors and typography. Designers without extensive knowledge of PHP or JavaScript will be able to create WordPress themes and share them with others. For site owners, it will be easier to customize the structure and appearance of their site for their needs, and more of the changes they make will carry over when they switch from one theme to another.
All site owners don’t want that level of control, of course. Things can get heated in the open office landscape when you discover that someone in marketing removed the blocks from the site header and set all headings in bright yellow. Fortunately, theme developers will be able to restrict how much of the theme should be editable in the Site Editor and Global Styles when they build their theme. We’ll likely see a lot of plugins for managing Site Editor and Global Styles access as well.
Just like with the block based content editor, adoption of Full Site Editing will probably be slow at first. I expect it’ll start with technology enthusiasts using free themes from WordPress.org for personal sites and smaller business sites. How long until it goes from there to businesses and organizations using premium block based themes, either sold by theme shops or built bespoke by agencies, is anyone’s guess. WordPress 5.0 is almost two and a half years old, and the Classic Editor plugin is still installed on more than five million websites.
If you want to try out Full Site Editing today, you can install the Gutenberg plugin and a block based theme, like TT1 Blocks. When both Gutenberg and a block based theme is installed, a new menu item will appear in your administration panel: ”Site Editor (Beta)”. As the beta label indicates, you are likely to run into bugs and probably shouldn’t use it on a production site just yet. When you do run into bugs, you can contribute to Full Site Editing by filing issues for those bugs to the Gutenberg GitHub project. You can also participate in the FSE Outreach program on WordPress.org, which coordinates testing of the Site Editor, Global Styles, and other features under the Full Site Editing umbrella.
On April 14, WordPress leadership met to demo the current state of the Full Site Editing features in the Gutenberg plugin. After the demo, they announced that some of the Full Site Editing features will be released in WordPress 5.8 in July, but that the biggest user facing features, the Site Editor and Global Styles (which contains sitewide appearance settings), will be targeted for WordPress 5.9 in December.
I’m really happy with this approach. The rushed release of the new content editor in WordPress 5.0 left little time for developers to properly support it by the time it was out, and led to many of them rushing to install the Classic Editor plugin instead. By giving theme developers the puzzle pieces for block based themes in WordPress 5.8, like the new site blocks and the theme.json structure, those developers will have plenty of time to create fully block based themes by the time the Site Editor and Global Styles are released in WordPress 5.9. And no excuses if they don’t.
Another reason for why I’m happy about this is that WordPress 5.9 also (in all likelyhood) will introduce a new default theme. Twenty Twenty-Two will be a good opportunity to establish best practices for block based themes, so having that development happen concurrently with the Site Editor and Global Styles seems like a good move. Like Justin Tadlock wrote on WP Tavern in March, work on Twenty Twenty-Two should already be underway.
The block based content editor released in WordPress 5.0 worked well enough in all decently constructred themes, regardless of whether developers had built the themes with blocks in mind or not. It was also enabled out of the box when users updated to WordPress 5.0, unless they had opted out ahead of time by installing the Classic Editor plugin.
The Site Editor, on the other hand, will only be available on websites that run themes with explicit support for it. How well the Site Editor is supported by theme developers will be crucial to what breakthrough Full Site Editing has, and there are some promising signs. Based on the activity on the Gutenberg GitHub project and the WordPress Slack, a lot of people seem to be taking a closer look at Full Site Editing now that WordPress 5.8 is up next. Hopefully that translates to theme developers starting to tinker with fully block based themes as well.
With the thousands of lines of PHP I wrote for Eksell in mind, I at least look forward to building themes that are both smaller and more flexible in the future.
Originally published in Swedish on WPSE.