I have been eagerly awaiting the moment when I could install a theme and truly test Gutenberg’s full-site editing feature. By and large, each time I have tested it over the past few months, the experience has felt utterly broken. This is why I have remained skeptical of seeing the feature land in WordPress 5.6 this December.
The Q theme by Ari Stathopoulos is the first theme that seems to be a decent working example. Whether that is a stroke of luck with timing or that this particular theme is simply built correctly is hard to tell — Stathopoulos is a team rep for the Themes Team. Gutenberg 9.1 dropped last week with continued work toward site editing.
Q is as experimental as it gets. The Themes Team put out an open call for experimental, block-based themes as far back as March this year. However, not many have taken the team up on this offer. If approved, Q stands to be the first block-based theme to go live in the official WordPress directory. It still has to work its way through the standard review process, awaiting its turn in the coming weeks.
On the whole, full-site editing remains a frustrating and confusing experience. I still remain skeptical about its readiness, even in beta form, to show off to the world in WordPress 5.6.
However, Q is an interesting theme to explore at this point for both end-users and theme developers. Users can install it and start tinkering with the site editing screen via the Gutenberg plugin. Developers can learn how global styles, templates, and template parts fit together from a working theme.
Using the Site Editor
The Q theme requires the Gutenberg plugin and its full-site editing mode to be enabled. Generally, requiring a plugin is not allowed for themes in the directory. However, experimental Gutenberg themes are allowed to bypass this guideline.
Stathopoulos pointed out that the theme is highly experimental and should not be used on a production site. However, he is hopeful that it will get more eyes focused on full-site editing.
He mentioned that several items are broken, such as category archives not showing the correct posts. This is a current limitation of the Query block in Gutenberg. However, one of the best ways to find and recognize these types of issues is to have a theme that stays up with the pace of development.
Currently, the site editor feels like it is biting off more than it can chew. Not only can users edit the layout and design of the page, but they can also directly edit existing post content — don’t try this at home unless you are willing for your post titles to get switched to the hyphenated slug. Should the site editor be handling the double-duty of design and content editing? If so, should design and content editing be handled in separate locations in the long term or be merged into one feature?
It feels raw. It is not geared toward users at this point.
The bright spot with the site editor is the current progress on template parts in the editor. Template parts are essentially “modules” that handle one part of the page. For example, the typical theme will have a header and footer template part. Currently, end-users can insert custom template parts or switch one template part for another. This opens a world of possibilities, such as users choosing between multiple header designs (template parts) for their sites.
The downside to the entire template system is that it seems so divorced from the site editor that it is hard to believe the average user would understand what is going on. Templates and template parts reside under the Appearance menu in the admin. The Site Editor is a separate, top-level menu item. Without any preexisting knowledge of how these pieces work together, it can be confusing.
Template parts worked for me in the site editor from the outset. However, they did not work on the front end at first. I continually received the “template part not found” message for hours. Then, at some point — whether through magic or a random save that pulled everything together — the feature began to output the previously-missing header and footer template parts.
Glimpse Into the Future of Theme Development
The Q theme has a scant few style rules, which it loads directly in the <head> section of the site in lieu of adding an extra stylesheet. It relies on the stock Gutenberg block styles on the front end with a few minor overrides. Most other custom styles are handled via the global styles system, which pulls from the theme’s experimental-theme.json config file (will be theme.json in the future).
It begs the question of whether themes will necessarily need much in the way of CSS when full-site editing lands.
If WordPress allows users to configure most styles via block options and global styles overrides, themes may not need much more than their config files. After that, it would come down to registering custom block styles and patterns.
If this is the future that we are headed toward, anyone could essentially create a WordPress theme. And, those pieces, such as template parts and patterns, could all be shared between any site. In that future, themes may simply not matter anymore.
Last year, Mike Schinkel proposed deprecating the theme system altogether and replacing it with web components.
“Rather than look for a theme that has all the features one needs — which I have found always limits the choices to zero — a site owner could look for the components and modules they need and then assemble their site from those modules,” he said. “They could pick a header, a footer, a home-page hero, a set of article cards, a pricing module, and so on.”
The more I tinker with full-site editing, the more it feels like that is the lane that it will ultimately merge into. Imagine a future where end-users could pick and choose the pieces they wanted and simply have it look right on the front end.
It is exciting to think about that possibility. Both Schinkel and I have more of a background in programming than we do in design. It makes sense from that sort of analytical mindset to put everything into neat, reusable boxes because reuse is a cornerstone of smart programming.
However, I worry about the state of design in such a system with so many replaceable parts. Will designers be able to take holistic approaches to theme development, creating truly intricate pieces of art? Will that system essentially create a web of cookie-cutter sites? Or, will designers simply find ways to think outside the box while within the constraints of the block system?
Thank you for the good overview. Is anyone getting full site editing to work with permalinks set to “Post Name”