Block themes are finally ready for serious client work

For several years our answer to "should we build this as a block theme?" was a polite no. Full site editing was promising, but the gaps were real: patterns were awkward to manage, global styles leaked in surprising ways, and editors could break layouts with a few careless clicks. That has changed. Over the last year we have started every new WordPress project as a block theme, including large marketing sites and WooCommerce stores, and we have not regretted it once. Here is why, how we build them, and where we still write PHP templates.

What changed

No single release flipped the switch. It was an accumulation of improvements that removed our objections one by one:

• theme.json matured. Design tokens for color, typography, spacing and layout are now expressive enough to encode a real design system, and per-block settings let us restrict options where editors should not have them.
• Patterns became manageable. Registering patterns from files in the theme, with synced and unsynced variants, gives us version-controlled building blocks that editors can use without touching code.
• Locking works. Template and block locking let us fix structure while leaving content editable, which was the missing piece for client handover.
• Performance improved. Block themes load only the styles for blocks actually on the page, and our block theme builds consistently start with smaller CSS payloads than our classic themes did.
• The editor stabilized. The site editor is no longer a moving target that changes significantly with each release.

How we structure a block theme for clients

Our starting point is a lean internal starter theme, not a commercial framework. Every project follows the same shape:

1. Design tokens in theme.json first. We translate the Figma variables directly into presets for palette, font sizes, spacing scale and content widths. Custom colors and arbitrary font sizes are turned off, so editors pick from the brand's options rather than inventing new ones.
2. Templates stay minimal. Page, single, archive, search and 404 templates are mostly composition: a header part, a main area, a footer part. Complex layout lives in patterns.
3. Patterns for every recurring section. Hero variants, feature grids, testimonials, pricing tables and calls to action are file-based patterns with sensible placeholder content, grouped into categories editors understand.
4. Custom blocks only where core falls short. We build dedicated blocks for interactive or data-driven components, such as a location finder or a comparison table fed from custom fields.
5. Locking at the right level. Structural patterns are locked against moving and removal where the layout matters, while text and images stay editable.

A good block theme is a design system that happens to live inside WordPress, with guardrails in exactly the places an editor might wander off.

The editor experience is where block themes most clearly beat classic ones. Instead of a page builder with hundreds of options, editors see a curated set of patterns that already look right. On the last three sites we handed over, the marketing teams built new landing pages in under an hour without asking us for help, which rarely happened with ACF-driven classic themes.

Where we still reach for PHP

Block themes do not mean no PHP. They mean PHP in the right places. We still write server code for:

• Dynamic blocks whose output depends on queries, user state or external data. These are rendered on the server with a render callback or render.php file.
• Complex query logic that the Query Loop block cannot express, such as faceted filters or relevance-ranked related content.
• Integrations with CRMs, search services and payment providers, which belong in a plugin rather than the theme.
• Performance-critical templates on very high-traffic archives, where we want full control over queries and caching.
• Heavily customized WooCommerce flows, although the gap here narrows with every release.

We keep a firm rule: business logic lives in a site-specific plugin, never in the theme. That way a future redesign can replace the theme without breaking functionality, which matters when a site is expected to last five years or more.

Trade-offs to plan for

Block themes are not free of friction. A few things we plan for on every project:

• Template edits in the database. When editors customize templates in the site editor, those changes live in the database and override the theme files. We agree up front which templates editors may change and train them to do so deliberately.
• Developer workflow. Changes made in the editor during development need to be exported back to theme files. We treat the files as the source of truth and review exports in pull requests.
• Legacy content. Migrating from a page builder is a content project as much as a technical one. We budget for converting key pages into patterns rather than trying to auto-convert everything.
• Training. A one-hour editor session focused on patterns, styles and locking pays for itself in avoided support requests.

None of these are reasons to avoid block themes. They are reasons to plan for them.

Our recommendation

If you are starting a new WordPress site in 2026, begin with a block theme unless you have a specific reason not to. If you are running a classic theme that works well, there is no urgency to rebuild; plan the move alongside your next redesign. And if you are fighting a page builder that makes every page heavy and every change risky, a block theme is likely the cleanest path out.

Our custom theme development work now defaults to block themes, and we pair it with Gutenberg block development for components core does not cover. Teams coming from design tools usually start with our Figma to WordPress process, which maps design variables straight into theme.json.

Plan your next WordPress build

Send us your designs or your current site, and tell us what your editors struggle with today. We will review it and reply within 24 hours with a fixed-price quote for a block theme built to last.