Does WordPress Need 1000s of Block Themes in the Era of Full Site Editing? – WP Tavern


Justin Tadlock
“I have so many design ideas in my head that I am about to make it my mission to singlehandedly fulfill [Matt Mullenweg’s] vision of 5,000 Full Site Editing #WordPress themes in the directory,” tweeted Brian Gardner earlier today.
Daniel Schutzsmith responded:
I’m just not seeing the need for more than one theme for FSE as long as I can override the look of it.
Would appreciate someone explaining why one theme like @frostwp COULDN’T just be the standard.
Making more themes feels like it defeats the concept of FSE altogether.
It is not the first time someone asked whether more than one block theme is necessary. In 2019, Rich Tabor proposed adding a base theme to WordPress itself, one upon which others would be built, if at all.
Even that was not the first time someone had pondered similar one-theme utopias throughout the platform’s history. Many framework-style parent themes have all made a run for it.
Let us assume for a moment that WordPress has reached a state where all themes no longer need custom PHP and CSS code. We are nowhere near that point yet, but we can imagine such a day might be possible in the relatively distant future. In this ideal world, templating, styling, theme-supported features, and plugin integration are neatly packaged into something configurable from the admin. In practice, users could control any aspect of their site’s front-end through the interface.
The problem is that someone still needs to make those customizations, and not everyone has a knack for design. One person’s ability does not automatically translate to all other users.
Perhaps a more crucial point is that not everyone wants to customize their site’s design. Some people simply want to find something that suits their style and move along.
There are alternative routes for arriving at the same destination, but themes are currently the only reliable vehicle.
Schutzsmith tweeted the following in response to Jamie Marsland, who likened the notion to asking Picasso for the canvas instead of the finished painting:
Themes and swapping out the whole thing is an old way of thinking. Sure a theme could = painting but I’m saying why can’t we just swap out the theme.json and get the same result? Why the need for themes at all when all we need to change is theme.json.
That is a future that I would not mind striving for. It is not insurmountable, but there is an uphill climb that WordPress will undoubtedly struggle with. Without a standardized CSS toolkit in place, switching theme.json files simply does not work. If WordPress tackles that problem, it takes us one step closer.
But theme.json only represents settings and styles. It says nothing about the structure of a website. Pre-configured templates are still necessary. Right now, that job sits squarely on top of the theme author’s shoulders.
If and when a well-designed user experience for full-page patterns lands in WordPress (related ticket), the template argument becomes less relevant. With such a system in place and enough variety from the pattern directory, some users might not require themes to handle this.
The only worthwhile argument I have for multiple — even 1,000s of — themes is the promise they make to the user: install this thing, and you get this result.
For example, a pizzeria owner installs WordPress on their site and begins looking for a design for their online presence. This is likely someone working all day in a hot kitchen and comes home exhausted at night. However, they hop on the computer to update tomorrow’s specials or tinker with a new homepage layout for a few minutes. Everything about that experience should be catered to their use case. As an owner, chef, spouse, and parent, they need to quickly get things done and spend the rest of the night with their family.
This and 1,000s of similar scenarios are why themes are as important today as they ever were. Not everyone has the privilege of time, the skillset, or the inclination to piece their sites together.
When done well, block themes offer a controlled experience that cuts out all the cruft. They feel like they were built for an audience of one while being flexible enough for public release.
Schutzsmith later tweeted in the thread that he liked Elementor’s Kits. These are predesigned website designs that span multiple industries.
Pattern category types, which are not currently in WordPress, could evolve into that role. The Block Pattern Explorer plugin enables the feature, but themes must add support for the types to appear.
In the following screenshot, I have created a “Profile Cards” type in a theme of mine, but it could be industry-specific:
It should be as easy as locating an industry-specific type and finding patterns for the pizzeria owner. A theme can offer that by either packaging patterns or pointing to those hosted in the directory.
I could see this evolving into more of a kit-like solution.
I disagree with Schutzsmith’s conclusion of needing only a single theme but not the questions he is asking. Our design community cannot simply say that themes should be “this one thing” because that is what they have always been. Its members need to continually ask: What is a WordPress theme?
The answer may be different to various groups of creators and users. If someone can get everything they need from the pattern directory without switching from Twenty Twenty-Two, maybe themes are irrelevant. If a creator simply likes building global style variations (theme.json files), WordPress should make it easy to use them on a wide range of sites.
However, many users will still need turnkey design solutions, and themes can be the best way to facilitate that. I do not know if that is 100, 1,000 or 5,000, but we will see how it goes.
I say yes.
Maybe we need to ask the question how many WordPress page builder plugins do we need. We have over 20+ of them.
I am honestly struggling to select a good theme for my blog as I am often stumbling upon different types of themes that doesn’t suit my needs or doesn’t have enough options to customize to my liking. I guess the themes actually need to have more options to customize them and more plugins to help with that.
The beauty of WordPress, something I hope survives this transition, is flexibility. If you want/need to build something from the ground up, it’s possible.
If you want to download a nearly-finished product, that’s available too. A hybrid approach is also there.
In that way, I think there should be room for as many themes as the market wants.
IMO, WordPress should facilitate a workflow for professionals and novices alike. Themes are a big part of this.
I actually started my no-code-low-code company to facilitate the concept of “designated operators” and “stack templates” to address what I feel is the greater foundation to these questions.
I have worked both SMB and enterprise site builds and gone through the tediousness of theme selection from several perspectives – be very careful not to confuse/muddy your theme selection with operations.
While I whole heartedly agree with Eric, it sounds he is a developer with a deeper understanding of DevOps.
Again I have worked with a variety of businesses (even a pizza restaurant like referenced), if you’re finding yourself overly focused on stylization and theme options (IMO) you’re very likely focused on the wrong things. You need to be more focused on “what tools/stack will best facilitate my business model and operation”.
Much more to Khushboo and Richard’s point. What plugins are compatible, what functions/features already exist in this theme, what page builder is best for us – these questions are much more cornerstone and better positioned to identifying a long term theme than simply “which theme”.
Imo WordPress is like Android, it’s meant to be tinkered with and to offer as many options as possible. There are dozens of android apps that basically do the same thing.
That said, I’m all for an “advanced” as well as “newbie friendly” route.
No. WordPress doesn’t need 1,000s of block themes. Will it get 1,000s of block themes? There are more than 20,000 classic themes in the org SVN and I think actually we could see many times more variation in design from far fewer block themes than would ever have been possible with classic themes.
In many respects working with block themes feels like going back in time and building theming from the ground up as it should have been, knowing what we know now.
It’s quite easy to use a theme.json for one theme with the templates and parts and patterns for another. I’ve developed a child theme generating tool to help you. Just visit
Choose the Theme style and preview it eg Avant-Garde
Then choose the Parent theme eg Twenty Twenty-Two, set a couple of other fields and you’ll get a child theme when you hit Download ZIP.
It’s easy if the themes share font and color slugs. For example, I used the tool to test X3P0 – Reflections (my theme) as the parent and Avant-Garde as the child/style. Colors were broken in many places, sometimes generating white text on a white background. Font sizes, particularly when defined in patterns, were not set because they exist in the parent but not the child theme.json in use.
It’s easy to move theme.json files from one theme to the next, but it is a broken experience at the moment because of the non-existent standards for slug-naming.
My theme is a simple one-pager. It’s easy enough to fix the inconsistencies. But, as block themes become more complex, the problems multiply.
Side note about the generation tool: the generator adds templateParts and customTemplates to the theme.json if they are registered in the child, even when those template do not exist in the parent. Right now, the HTML template files are not included at all.
Also, that’s a pretty awesome tool.
Thanks for trying the tool Justin. I’ve raised an issue against the tool and updated the Limitations.
“The problem is that someone still needs to make those customizations, and not everyone has a knack for design. One person’s ability does not automatically translate to all other users.
Perhaps a more crucial point is that not everyone wants to customize their site’s design. Some people simply want to find something that suits their style and move along.”
Both is obviously true, yet I can’t help but wonder what that means for the actual size of the target group of full site editing? What is the actual benefit of using a fse-block-theme for someone who doesn’t want to do it himself (beyond setting options)?
This may have a different answer for different folks, but the biggest benefit to me is the standardization across the platform. When WordPress, plugins, themes, and users can all universally communicate via the block and global styles systems, they can work together in ways that they never have been able to do before. This can surface itself in many ways. Sometimes, it means fewer scripts and styles necessary on the front end. It can mean a plugin’s front-end output matching the theme’s design. Maybe it is a more accurate WYSIWYG post editor. Or, countless other improvements, some of which we probably haven’t even thought about yet.
Using a block theme doesn’t mean you need to customize your site’s design no more than classic themes require it. However, users will still benefit from the standardization under the hood.
Your email address will not be published.

document.getElementById( “ak_js_1” ).setAttribute( “value”, ( new Date() ).getTime() );
This site uses Akismet to reduce spam. Learn how your comment data is processed.
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



Please enter your comment!
Please enter your name here