Two architectures, still
Block themes have been the platform's stated direction for years, and in 2026 they are mature: theme.json controls the design system, templates are HTML with block markup, the site editor lets clients edit headers and footers, and patterns and pattern overrides give you reusable, partly locked components. Most new WordPress builds should start there.
Classic themes, PHP templates with functions.php and the customiser, are not dead. They remain the right answer for a specific set of projects, and pretending otherwise leads to builds that fight the tooling. Here is how we decide.
Where block themes win
The editor experience. Clients editing in the block editor with a well-configured theme.json get a constrained canvas that looks like the site. Colour and spacing choices are limited to the design system. Patterns give them starting points. Pattern overrides let you lock structure while allowing content edits. This is the best editing experience WordPress has ever had for a non-technical client, and it is the argument.
Design tokens in one file. theme.json declares the palette, type scale, spacing scale and layout widths, and both the editor and the front end read them. A colour change is one line. This is close to how modern front-end systems work and it removes the editor-versus-front-end drift that plagued classic builds.
Performance by default. Block themes load only the block styles the page uses. A classic theme's monolithic stylesheet is replaced by per-block CSS, and the platform handles it.
Header and footer editing without a developer. The site editor lets a client change the phone number in the header themselves. On a classic theme that is a template edit or a customiser setting you had to build.
Alignment with the platform's future. New editor features land for block themes first, or only. A classic build is choosing to be on the older path.
Where classic themes still win
Heavy plugin ecosystems that assume PHP templates. Some WooCommerce extensions, membership plugins and page builders still expect classic template hooks and behave unpredictably in block templates. If the project's plugins are the reason for the build, check their block-theme support before committing.
Sites whose layout logic is genuinely dynamic. Complex conditional templates, per-user rendering, deep integration with external data at template level. Block templates are HTML; the logic has to move into blocks or template parts, which is doable but adds indirection. A PHP template with a few conditionals is sometimes just simpler.
Teams and clients who already live in a classic setup. Migrating a working classic theme to blocks for its own sake is a project with cost and risk and no client-visible benefit. If the client is happy editing with ACF fields in a classic theme, leave it.
Page-builder sites. Elementor and Divi sites are classic-theme sites in practice. Moving them to blocks is a rebuild, not a theme swap.
The hybrid nobody talks about
Many of our builds are block themes for the pages and ACF-backed custom post types for the records: services, staff, locations, prices. The editor gets blocks where the content is a document and fields where it is data. The theme is a block theme; the templates for the custom post types use a small number of custom blocks that render fields. This gets the block editor's ergonomics and the structured data a booking-led business needs.
The migration cost, honestly
Moving a live classic site to a block theme is not a theme switch. It is: rebuild templates as block markup; rebuild the header and footer as template parts; move design decisions into theme.json; convert any custom template logic into blocks or filters; check every plugin's output in block templates; and retrain the client. On a typical business site that is one to three weeks. Worth it when the client edits often and the classic theme is fighting them. Not worth it when the site is stable and rarely edited.
The decision, compressed
- New build, business site, client edits content: block theme, with ACF for records.
- New build, plugin-heavy store or membership site: check plugin compatibility first, then block theme if it holds, classic if not.
- Existing classic site, stable, rarely edited: leave it.
- Existing classic site, client fighting the editor, redesign due anyway: migrate to block as part of the redesign.
- Page-builder site: that is a rebuild question, not a theme question.
What we build
New client sites are block themes with a theme.json design system and ACF-backed post types for structured content, because it gives the client the best editor and gives us the best control. When we inherit a classic site, we do not push a migration unless the redesign is happening anyway. The right theme architecture is the one that matches the client's editing life, and that is a question about the client, not about which is newer. If you are scoping a build and want the call made for your case, that is part of the WordPress work.