Justin Tadlock
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.
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.
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”
Hey Justin,
Thanks for the mention.
P.S. I found out about it from all the pingbacks I started getting from websites that copy and repost WPTavern content I assume to generate page rank for their websites. Too bad you can’t easily do something about that. :-(
A lot of theme developers have outright ignored Gutenberg cause it doesn’t give users enough ability to do more templating and full site editing—but they fail to see that it’s getting closer every day.
We ended up bypassing block patterns (for now) because we built our own templates modal window. Plenty of enhancements to the blocks api has made it possible to have what amounts to mostly full site editing outside the navigation system and widgets for footers and sidebars.
For me, that’s good enough with the help of customizer.
We made our own blocks plugin and templating because patterns and the like didn’t exist when we started. It works with most of the default WordPress themes going back to 2019 and our own themes, one of which is already on the theme repo.
I’d be interested to see why more theme developers aren’t implementing more of the newer block api features. They’ve really come a long way. Our next plugin release is using the blockpreview component and animations. It’s miles easier to use for our clients.
My guess is developers are all too hung up on elementor and other page builders despite their shortcomings…
Hi guys
Great thoughts, once again.
I’m a designer. And programming passionate (amateur level but pro curious).
We can feel a big enthusiasm around FSE. I am.
But it also feels WP’s main concern is to allow everybody to design sites. Great, nothing against it. For me, probably it will be super useful – replacing other builders.
But are the rest of the solutions being neglected or ending? I don’t have the know-how in WP to be confident about this answer but I wonder.. what about users/clients who don’t want to design?
Will it be possible to make a good & solid template/pattern(?) that the client just fills the data and the info shows exactly in that beautiful spot where it was supposed to? And with a dynamic growth potential?
Imagine a Newspaper site. Or big organization’s one. Do they want to play around with the design/blocks at any time? Can we control that?
Guttenberg comes from Printing, Readability, Clearness. Will FSE be a bit chaotic?
All the best
Will FSE be a bit chaotic?
They are aware of this possibility and, in fact, there is an interest in providing tools to adjust the level of control that should be available to end users.
For more clarification about this subject, read the following article from the project’s lead architect:
https://matiasventura.com/post/thoughts-on-themes/
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…
© All Rights Reserved. Powered by WordPress, hosted by Pressable
source
