If you’re building a WordPress theme you plan to develop and maintain over time, whether it’s open source, freemium, or fully commercial, I don’t think a block theme is the right call.
Hybrid is the way to go.
Here’s why, and what nobody’s talking about when it comes to the real work of theming in the world of “The Block Editor” 2026.
1. The plugin problem and “plugin territory.”
One of the biggest selling points of block themes was that you don’t need to know PHP. Just HTML, CSS, and theme.json.
Except that’s not how it works in practice. The moment your theme needs anything beyond basic block layouts (custom blocks, dynamic logic, settings pages, support for a platform plugin) you need a companion plugin. And plugins require PHP.
Block themes didn’t eliminate the PHP requirement. They just moved it into a second thing you have to ship.
Now, the .org theme directory enforces this separation on purpose. “Plugin territory” exists so that users keep the functionality of your custom blocks and shortcodes when they switch themes. That’s the theory, and it’s not wrong.
But who does this actually serve? If your theme is the thing styling those blocks and shortcodes, switching themes means they render unstyled anyway. Shortcodes dump raw output. Blocks fail a little more gracefully (but they still won’t look right without the theme that designed them).
And who is switching themes all that often? No one. Not on a commercial site they’ve invested in.
So you end up with a forced architecture split that protects against a scenario that rarely happens, at the cost of a worse experience for every user every day.
“Install our theme and also this required plugin” is not better.
It’s worse with extra steps.
2. theme.json is great… but you still need stylesheets.
The current theme.json approach for styling core blocks is wonderful. I genuinely appreciate the direction WordPress is going and I’m team Block Editor all the way.
But it doesn’t mean you get away from needing stylesheets. Sass or CSS: you’re going to need them.
People aren’t building sites with just core blocks. They’re installing plugins. They’re adding their own functionality. The job of the theme developer is to set a bunch of defaults on core blocks via theme.json, and then replicate all of those styles in a stylesheet.
Here’s the annoying part: if you style the blockquote block in theme.json, you also need to replicate that in style.css … but exclude the core selector for that block. Otherwise you’re doubling up and putting styles in a stylesheet that block editor settings can’t “undo”.
Welcome your new best friend: the CSS :not pseudo-class.
It’s tedious, but necessary. It means when someone uses a core blockquote, it looks the same as when a plugin adds its own blockquote markup. Consistency across the whole site.
The only way around this would be if every plugin developer adopted all of the core block selectors. That’s not going to happen.
Could AI generate that stylesheet for you? Probably. “Here’s my theme.json. Now replicate these styles in style.css, excluding core block selectors.” That’s a real use case. But the work still needs to happen.
3. The triple-styling nightmare.
When you’re building a platform plugin like ours (Paid Memberships Pro) alongside a theme, it gets even harder.
The plugin needs its own styles. The theme needs to replicate those in a generic way so all other forms on the site carry consistent styling. And then you have to bring those same styles into the block editor for elements like the comments block, search block, and whatever else WordPress decides to make editable.
That’s three places. For the same visual treatment.
I want every form on the front end to look the same. That means the core PMPro styling is the boss. Our theme replicates it generically. And then we also have to account for other heavy-handed plugins that ship their own styles and override everything.
It’s a lot of surface area. And there’s no shortcut.
4. Colors are deceptively hard.
Classic themes could get away with never registering a color palette. A hybrid theme should register one.
But here’s where it gets complicated.
If you let users pick dynamic colors, you need to inject them into theme.json via a filter so they are available in the editor. You may also want those output as CSS custom properties in a style tag in the head (your own root variables or you’ll be using the --wp--preset--color-- ones in your stylesheet which is fine, but verbose).
WordPress stores custom color palettes for block themes in the posts table. If you’re building a classic or hybrid theme, you’re probably storing colors in the options table in theme_mods. That’s fine, but it is just something to be aware of.
And then there’s color math. Rather than asking users to set a primary color AND a hover variant of that color, you should be computing the hover state yourself. WordPress has some JavaScript-based color helpers. But honestly, you’re better off doing the math at the time of palette creation and storing the computed values (darkened and lightened tints) in the database alongside your named colors.
Handle it once, store it right, use it everywhere.
There’s no clean takeaway here. Just the rumblings of someone who’s been WordPress theming for – gasp – around 20 years. And what it looks like for me in 2026: a maze of redundancy, and the “just build a block theme” advice that oversimplifies the reality for anyone building something they plan to maintain.
