WordPress Block Themes
12th February 2024
I’ve recently been experimenting with WordPress “Block Themes”, which provide the capability of customising almost all parts of a website from the block-based site editor. This is very powerful, but the user experience for the site creator can be complex, less intuitive and sometimes slower than using the traditional customiser. I wonder if I am alone in finding this, and whether the WordPress team are intending to tidy up the UI.
Previously, traditional themes allowed only the content areas to be edited, together with those parameters of site design that the theme developer chose to expose through a customiser. The customiser is generally easy to use. Parameter fields in the customise are usually clearly labelled and intuitive. By contrast, the new site editor for block themes presents a sometimes baffling array of heavily-nested blocks. It isn’t always obvious which block needs customising to achieve a particular goal. Inner blocks are often constrained by containing blocks, and it can take a little detective work to identify what is constrained where, which might not even be in a block, but in themes.json. Creating menus with the new Navigation block is particularly fiddly and time-consuming compared with the previous menu tool in the Dashboard.
There are cases where parts of the site editor do not fit together seemlessly either with other parts of the site editor or with the Dashboard. Confusingly, the Dashboard top toolbar disappears when the site editor is used.
History of blocks
Some background to the evolution to blocks. I distinguish “developers” – people that develop WordPress, themes, plugins and other elements – from “site creators” (or just “creators”) – those that create sites and site content using the tools created by the developers. Developers need to know the underlying technology of WordPress: html, css, php, xml, mysql, json and so on. Creators need to know little or nothing of the technology, just a basic understanding of how web pages work, and how to use the tools created by the developers to create websites.
Pre-2018 – “Classic” content editor
Before around 2018, creators had a limited set of tools to create sites. Page content was created with a word processor like editor. This provided a familiar interface to newcomers to web page creation, but had limitations. It was fine for text and images, but web pages often have many other types of content: data entry fields, buttons, e-commerce functions and so on, and more complex layout possibilities.
2018 – Block editor
From 2018, WordPress started migrating to a “block” interface, where content was assembed in a series of blocks, each for different types of content such as a paragraph of text, an image, a picture gallery and many function-specific types. This is much more flexible and powerful, but less intuitive. It steepens the learning curve for creators. In the early stage, blocks were limited and rather clunky, and many creators resisted using them, staying with the “classic” WordPress editor. (Some still do.) However, since the early 2020s the range and power of blocks has made it worth while for most creators to learn how to use them.
In my view there is still a residual need for the classic word processor style of page editor. Some content creators need to know little about web page structure and just need to put text and pictures on a web page. For them, the classic page editor is familiar and sufficient.
2021-23 – Full Site Editing – Block themes
From 2021, WordPress introduced the concept of “Block Themes”, also known as “Full Site Editing”, and this development was largely complete by 2023.
Prior to Block Themes, creators could use the block interface to edit content in one or more content areas on a page. However, most web pages include multiple other specialised peripheral areas of content around the main content area(s), including headers, footers and sidebars. These areas often include special content such as menus.
Creators did not have complete control of a website; developers produced “themes”, which defined the look and feel of the webite, including layout, colour schemes, typography and so on. Themes were written in php and css, beyond the knowledge of most creators. Creators chose a theme (there are are over 10,000 themes to choose from on the main WordPress site), and the theme usually provided a “customiser”. The customiser is a set of menus that gives a degree of control over the theme. Each theme has its own customiser. This customiser normally included control of what goes in headers and footers, and some level of control over colour schemes and type faces. This is how all themes worked pre-2021, and many still do. These are sometimes called “classic” or “traditional” themes.
The WordPress community wanted to provide creators with a more consistent style of control over the overall website, and to be able to do this with an extension to the block paradigm. Enter Full Site Editing (FSE), and Block Themes that implement it.
With block themes, instead of a customiser to control the layout of the pages and peripheral areas of content, the creator can edit the whole site with the block editor, in a similar way to editing the main page content. Page layout and the content of headers and footers is often the same on all pages on a website. Thus these elements are not edited separately for each page. Rather, there is one or more “templates” that define the layout, headers, footer and so on. There might be more than one template; for example for one or two content column pages, for pages with and without sidebars and the like.
In practice, editing templates with the block editor is not a seemless extension of using the block editor on page content. Page content is often a sequence of blocks, one after the other. Templates are often composed of many blocks deeply nested. This website uses a simple theme, but this paragraph is in a block nested in other blocks 4 deep. When a block is nested in another block, it inherits some of the properties of the containing block. The containing block(s) may constrain what you can do in a block, and it isn’t always obvious where the constraints come from; is it from the immediate containing block, or an outer containing block? Some constraints come from outside the block structure in a controlling “theme.json” file. This can be quite confusing to some creators (including me).
A further issue is that some functions that were implemented in a fairly intuitive way in classic themes are rather more difficult to achieve in block themes. An example is menus. Menus are now created in “navigation” blocks. These are quite powerful, but I find them rather confusing, and significantly more time-consuming to use than the previous menu tool. This applies to other aspects of site design. With classic themes creators have limited control of site design, but what control the theme developer provides is normally simple and intuitive to use. Block themes provide more control, but in less intuitive and sometimes more time-consuming way.
Occasional site creators may just want to find a suitable theme and tweak it slightly with headings, logo, colours and so on, and then create pages. For them, traditional themes with a customiser may be ideal. Even with block themes I think there is a need for themes that provide a simplified customiser interface for limited site tweaking.