WordPress block themes in 2025: an honest take after a year of building with them

Block themes — the WordPress full-site editing approach that has been promised for years — finally crossed the threshold for us in 2024, and 2025 was the year we shipped more block themes than classic themes for the first time. Here is the honest after-action review.

What block themes finally got right: the editor experience for content editors. A non-developer client can now genuinely build, rearrange, and style pages without breaking the design system. With the right theme.json setup and a tight collection of patterns, we hand off sites where the marketing team can spin up new landing pages in an afternoon — without calling us, without breaking the brand.

Theme.json is the unsung hero. The ability to define the entire color palette, type scale, spacing scale, and component variants in a single JSON file, and have the editor enforce them, is genuinely transformative. The old battle of 'designer ships a system, developer implements it, content editor breaks it within a week' is mostly over. The system enforces itself.

Patterns are the second big unlock. Instead of building one-off pages, we build a library of patterns (hero, feature grid, pricing table, testimonial wall, FAQ) that the client can drop into any new page. Each pattern is on-brand by default because the theme.json constraints prevent off-brand combinations.

Where block themes still struggle: complex template logic. Classic themes use PHP and template hierarchy that any WordPress developer can read and extend. Block templates use HTML files with block markup that is harder to debug, harder to version-control meaningfully (the diffs are noisy), and harder to programmatically generate. For sites with deep custom logic, classic themes are still our default.

Custom blocks are also still painful. The block editor's React-based block development is powerful but the developer experience is rough — webpack, build steps, npm packages, and a learning curve that puts off most WordPress developers. The promise of 'every developer can build blocks' is true in theory and false in practice. We typically write blocks in ACF (Advanced Custom Fields), which solves 90% of the use case at 10% of the complexity.

Performance is mixed. Block themes can be very fast — better than classic themes in some cases, because they avoid the bloat of legacy theme frameworks. They can also be slower, because the editor ships JavaScript to the storefront for any interactive blocks. The audit pattern is the same as classic themes: check what scripts are loading, prune ruthlessly, do not trust the defaults.

Migration from classic to block themes is non-trivial. We have done several and the work is essentially a rebuild — content can be migrated, but the theme architecture is different enough that you cannot just port the old PHP templates to block templates. Budget the migration as a fresh build, not a refactor.

Plugin compatibility has improved dramatically in 2025. Most major plugins (WooCommerce, Yoast, Gravity Forms, ACF, Elementor) now play well with block themes. The exceptions are mostly older niche plugins that have not kept up — and those are usually a sign that you should look for a maintained alternative anyway.

Our recommendation in 2025: default to block themes for marketing sites, content sites, and small commerce sites. Default to classic themes for custom commerce, complex membership sites, and any project where the back-end logic outweighs the front-end design work. The two approaches will coexist for years, and pretending one universally beats the other is just incorrect.

If you are starting a new WordPress project this year and your team is comfortable with the block editor, go block themes. The editor experience for clients alone is worth the migration cost. If your team is deep in PHP and the project is heavy on custom logic, stay classic and revisit in 2026 — the platform is still moving fast.