WordPress turned heads in 2018 when it introduced the “Gutenberg editor” to the long-standing blogging and content-management system. The editor was completely rebuilt to allow individual pieces of content (referred to as “Blocks”) to be moved around by the user, and to allow developers to provide their users with custom elements like image carousels and interactive forms.
Some people loved the new editor and some people hated it, but even those who remained loyal to the system all agreed that the new version needed time to ripen.
Fast-forward to 2020. Someone stated that providing users with a load of blocks and no instruction for how best to use them was like providing an untrained cook with ingredients but no recipe.
This situation was massively improved by the addition of Block Patterns: pre-defined groups of blocks which the user can add to a page or post as a starting point. These patterns allow users to quickly put content together, without having to think about what options may be available.
The Gutenberg project isn’t just about the WordPress editor, but a four-stage project to make WordPress a complete and highly-efficient content publication system. Stage two is heading towards completion with the upcoming addition of “full-site editing”: integrated technology to allow any part of a site to be edited using a WYSIWYG editor. From the page and post content to the surrounding page elements like navigation, header, and footer.
In the future of WordPress, starting with version 5.9, everything is a block. Once a user has learned how to interact with the Gutenberg editor, it’s simple to modify the layout of the page, editorially create and assign a page template, and manage what used to be called “sidebars” within the same, common editor environment. Want to add a new “sidebar”? You don’t have to code anything: you can just edit a page (or post) template using the Gutenberg editor.
User roles and access controls
Helpfully, the full-site editor is restricted to users with specified roles. For example, a user with the “author” role can only select an existing template for their post, not create or edit new templates.
Individual layouts for single posts and pages
Templates, which an administrator can define using the Site Editor, can help to create a range of different layouts for the individual posts. On this site, I have implemented single post templates for posts which have a large leading image, posts which have a video as the leading media element, and for posts which are only text (like this one).
The leading picture, video or header (including post title, category and publication date) are all blocks, placed in a block template separately from the actual content.
The area lower down the page in which a grid view of latest blog posts are displayed is also controlled through the block editor; automatically appearing on every individual post view. The footer is comprised of blocks, which I can modify directly in the editor, without any coding.
How does full-site editing change theme development?
With the initial release version, the main thing that developers have to know is that there is a (relatively) simple theme.json configuration file for stuff like colours and typography. (Note that some options on the linked page are not yet supported unless you’re using the Gutenberg plugin. I would recommend that you don’t use the plugin on a live site, because it contains breaking-edge features that aren’t always complete or stable.)
The bigger change is that the template structure is moving from PHP to HTML. Files like single.php or archive.php are no longer used. New files like single.html or archive.html are drawn from the block-templates folder in the theme.
The first question which occurs, as a developer, is “how do I make parts of a template dynamic?” The answer is that the part of the template which needs to be dynamic – for example, rendering the current date or loading other posts which are related to the current one – is a block. If the block isn’t delivered by core, you can make your own, using PHP, ACF, or React with server-side rendering.
Keep the phrase “everything is a block” in your mind, and it will quickly sink in.
Want to learn more?
Feel free to leave a comment on this post, or drop me a line on Twitter @howellsmead.