Category: WordPress

Block themes promised the end of functions.php, the death of page builders, and a future where every editor was a designer. After 18 months running them in production alongside classic themes, here is the honest no-hype comparison.

Where block themes won

• Template editing in the admin. Editing the footer or 404 page in the Site Editor without touching code is real and works. Designers love this.
• Global styles. One JSON file (theme.json) controls colours, typography, spacing across the whole site. Changes feel atomic and predictable.
• Asset weight. Block themes ship less CSS by default. Lighthouse scores nudge up.

Where classic themes still win

• Deep customisation. If your design has bespoke layouts, custom post type templates, or specific hook integrations, classic theme files are still faster to write and easier to debug.
• Ecosystem. The plugins and theme add-ons you have used for ten years almost all still target classic patterns. Block-theme integrations are catching up but lag.
• Client comfort. Clients trained on Elementor or Divi do not necessarily benefit from the Site Editor. Some find the block paradigm slower.

The honest middle

Most production sites we manage now are hybrid: a block theme for the chrome (header, footer, post templates, 404, search) and a classic-style child theme for the bespoke template parts. This is not a fence-sit; it is a load-balance. The block side gets the editing convenience, the classic side handles the cases that genuinely need PHP.

Migration is the gotcha

Moving an established site from classic to block is rarely worth it. The migration eats weeks, breaks integrations, and the visible benefit to the client is small. New builds are a different story — start with block, fall back to classic templates where you need them.

The short version

Block themes are now the default we reach for on new builds. Classic themes are not dead — they are the right tool for sites that need deep custom work and for established sites where migration is more risk than benefit. The “block themes are the future” framing was true; the “classic themes are obsolete” framing was not.

PHP 8.3 is the deadline most WordPress hosts moved to in 2025. Our migration of 47 client sites broke things on six of them — about one in eight. Here is the checklist that handled the other 41 cleanly, and the patterns of the six that did not.

The pre-migration checklist

1. WordPress core on the latest minor. 6.5+ is fine with 8.3. Older cores have unresolved deprecation warnings that are now fatal.
2. All active plugins on their latest version. Plugin compatibility regressions are 80 percent of the breakage we saw.
3. Theme PHP files audited for deprecated functions. create_function(), the old each() pattern, dynamic class properties without declaration.
4. Test a staging clone first. Always. We never migrated production without a staging pass.

What actually broke

Across the six sites that hit issues, the patterns were:

• Dynamic properties on undeclared classes. 8.2 deprecated this; 8.3 makes it a fatal in some cases. Almost always in an abandoned plugin we then replaced.
• Calling strtolower() on null. Strict type changes mean what used to be a soft warning is now a fatal. Audit any code that handles user input or plugin metadata.
• Removed utf8_encode and utf8_decode. These were deprecated then removed. Old import plugins were the worst offenders.
• SOAP and ext-imap quirks. Two sites used ancient SOAP integrations that needed a workaround.

The migration step-by-step

1. Clone production to staging.
2. Switch staging to PHP 8.3 in your host’s control panel or via WP-CLI’s host-specific command.
3. Visit every public template and the entire admin. Note any white screen or error.
4. Tail wp-content/debug.log for one hour of normal use. Almost everything that will fail in production fails here first.
5. Run WooCommerce checkout end-to-end on test cards if it is a store.
6. Cut over production. Keep the 8.2 environment available for 48 hours as a rollback.

The single most useful thing

Enable WP_DEBUG_LOG with display_errors = Off on staging for the migration window. Every deprecation that will bite you logs there first. It is the cheapest insurance you can buy.

8.3 is faster and the migration is usually clean. The pattern across the sites that broke was always “old plugin nobody touches” — the migration was a useful prompt to retire those.

WordPress Multisite is one of those features people either love or never touch. It saves time on the right job and creates pain on the wrong one. After running both models for client portfolios, here is when each actually wins.

When multisite wins

• Many similar sites with shared management. A university with 80 department sites. A franchise with 200 location pages. A media group with 12 brand sites that all share the same plugin stack. Updating once and propagating is the whole point.
• Centralised user management. One user account with different roles on different sites is genuinely useful when content teams overlap.
• Shared media library when the assets logically belong to one organisation.
• Tightly controlled plugin set. The super-admin enforces what is allowed; site admins cannot install rogue plugins. This is a feature for IT teams.

When separate installs win

• Sites with different stacks. One needs WooCommerce, another needs LearnDash, another is a simple brochure. Multisite forces you to share more than you want.
• Sites that need different update cadences. Some clients want every WordPress update yesterday; others wait six months. Multisite’s “update everything together” is hostile to that.
• Sites with very different traffic profiles. One viral site can bring down the entire multisite network. Separation isolates the blast radius.
• Sites you might sell or hand off. Migrating one site out of a multisite is painful. Separate installs are portable.

The honest gotchas of multisite

• Plugin compatibility is worse. Some plugins simply do not work on multisite. The list shrinks every year but still exists.
• Hosting choice narrows. Many cheaper managed hosts do not support multisite or charge a premium for it.
• Backups are all-or-nothing for the network. Per-site restore is rarely as clean as you want.
• Subdomain vs subdirectory is a one-way decision. Pick wrong and migration is a project.

The honest gotcha of separate installs

Tooling burden. Running 30 separate WordPress installs requires the kind of automation we covered in our 50-sites article. Without it, the “freedom” of separate installs becomes “30 things to remember to update”.

The shorthand

If the sites should be managed together because they share an organisation, a stack, and a release cycle: multisite. If the sites only happen to be managed by the same agency but are otherwise independent: separate installs. The wrong choice is fixable but expensive — make it deliberately on the first build.