1. Home
2. Blog
3. WordPress
4. WordPress block themes and full site editing

WordPress

WordPress block themes and full site editing

WordPress block themes are how I want long-lived WordPress and WooCommerce sites to be edited in 2026: templates and patterns in the site editor, design tokens in theme.json, and PHP only where the platform still needs it. I am Alan Vo, a Gold Coast developer with 18 years on business sites and shops. Full site editing is no longer a beta slogan. It is a production choice, and it fails when you ship a block theme with no pattern library and hope merchandisers will invent your layout system from core blocks alone.

This note is for teams leaving a classic PHP theme or a page builder, and for anyone comparing Gutenberg vs Elementor who needs the theme-side half of that argument. If the storefront needs drawers and steppers, pair this with the WordPress Interactivity API so the theme is not only pretty in the editor.

Why WordPress block themes matter in 2026

WordPress block themes matter because the people who change the homepage are rarely the people who deploy PHP. A classic theme with twenty get_template_part files is fast in my editor and opaque in theirs. A block theme exposes header, footer, home, archive, and product templates as documents they can open. That is the point of full site editing. The risk is giving them enough rope to break spacing on every URL.

WordPress has been moving the default theme line toward blocks for several releases. Twenty Twenty-Four and Twenty Twenty-Five are not client themes, but they are the reference for how templates, parts, and patterns are supposed to sit. Client work still needs a brand theme: constrained colours, type scale, and a small set of patterns that match how the business actually publishes.

I do not treat a block theme as "no code". WooCommerce, memberships, and ticketing still need PHP for queries, schema, and cart behaviour. The win is putting chrome and landing layout in templates instead of a page-builder canvas, while keeping business logic in plugins and a thin functions.php or a site plugin.

Performance is a reason, not the only reason. A block theme can still enqueue a zoo of block styles. The advantage is you own theme.json, you can limit block types per template, and you can stop loading a builder runtime on the shop. Editors still need training. A site editor with every block unlocked is how you get five different hero designs in a week.

How WordPress block themes actually work

WordPress block themes actually work as a theme.json file plus HTML templates in /templates and /parts, with optional patterns in /patterns. There is no header.php required. The site editor writes to the database when someone customizes a template. Those customizations override theme files until you reset them. That override story is the ops detail I explain on day one, because a deploy that "doesn't change the header" often means the database copy won.

theme.json holds settings and styles: palette, fonts, layout content width, spacing scale, and which core blocks are allowed to use which options. I keep the palette short. Eight brand colours beat forty "maybe we will need coral". Appearance tools I do not want (drop shadow on every group, arbitrary font sizes) get turned off. Editors then work inside a system instead of painting.

Templates are block markup. front-page.html, single.html, archive.html, and WooCommerce templates such as single-product.html when the shop is block-based. Template parts are reusable chrome: header, footer, query loops you want identical. Patterns are the merchandising kit: "product story", "event hero", "three cards". I register patterns in PHP or as files with slugs and inserter categories so they show up with names humans understand.

The official block themes handbook is the map for theme.json version, template hierarchy, and how parts resolve. I follow it instead of copying a random starter that still ships a jQuery slider in assets.

PHP still belongs in a block theme when:

• You need a dynamic block (render.php) for stock, price, or a ticketing query.
• You need functions.php to enqueue one view script, register block styles, or constrain allowed blocks.
• You need Woo hooks that have no block equivalent yet.

PHP does not belong as a second layout system. If the header is a template part, do not also print a hard-coded nav in functions.php "just in case".

Classic theme hybrids exist: theme.json in a PHP theme. That is a valid step. It is not a block theme. I use the hybrid when we cannot fund a template rewrite but we want tokens. I do not promise full site editing on a hybrid.

Templates, patterns, and theme.json in production

Templates, patterns, and theme.json only work in production if you version them and decide who may edit what. I keep the theme in git. I treat database template overrides as content. If a client customizes the header in the site editor, that lives in the DB. A later theme update to parts/header.html will not show until they reset or we sync. I document that in the handoff, not in a private ticket.

Synced patterns (reusable) are for chrome that must stay identical: announcement bar, footer legal, a trust row. Unsynced patterns are starting points for landing pages. I almost never give editors unregistered "freeform" on the product template. The PDP is a selling machine. The home page can be looser if the brand wants campaigns.

WooCommerce block templates need extra care. Cart and checkout blocks are a separate migration. Do not switch single-product.html to blocks and forget gallery, add to cart, and tabs still have to sell. I have a dedicated note on product page blocks when the shop is Woo-first. For a content site, single.html with a post content block and a query for related posts is enough.

Global styles in the editor can fight theme.json. I lock what I can. I still review the global styles panel after a client session because a one-click font change there ships to every URL.

Child themes are thinner in the block world. A child can override templates and theme.json merge. For agency-style multi-site work I still prefer a parent with clear slots rather than five children that drift. This portfolio's own theme work taught me the same lesson: constrain first.

Production checklist for a block theme merchants can edit

A block theme merchants can edit is a shipped kit, not a Twenty Twenty-Five fork with the logo swapped.

1. Write theme.json with a short palette, type scale, and content width that match the brand, not the starter.
2. Ship header and footer parts that work at 320px and 1280px without a builder.
3. Register 5 to 12 patterns that match real pages: home hero, category intro, product story, event block, FAQ, CTA.
4. Lock or disable blocks that break the system (random third-party carousels on the PDP).
5. Decide which templates editors may customize. Product and checkout are usually developer-owned.
6. Put interactive bits in Interactivity API blocks or small view scripts, not in a kitchen-sink animation plugin.
7. Enqueue block styles only for blocks you use. Do not load the entire library "for the inserter".
8. Test the site editor as a shop manager role, not as admin. Capabilities surprise people.
9. Export a backup of customized templates before each theme deploy.
10. Train on patterns with a 30-minute recording. The UI is not self-explanatory if they came from Elementor.
11. Keep PHP for Woo, forms, and schema. Do not hide a 400-line shortcode in a custom HTML block.
12. Accessibility: skip link, focus styles, nav overlay, and heading order in patterns. The site editor will not save you from a pattern that starts at h4.

Sophia Pro was built as a multipurpose WordPress and WooCommerce theme aimed at speed, SEO, and shop UX. That product work is why I am picky about pattern names and default templates. A theme that is "flexible" but has no opinion becomes Elementor with extra steps.

What breaks in WordPress block themes

WordPress block themes break when the database copy of a template diverges from git, when Woo templates are half classic and half blocks, and when every plugin registers ten blocks that appear in the inserter.

Other failure modes:

• Duplicate headers: a block part plus a leftover classic wp_head menu walker.
• Fonts loaded twice, from theme.json and from a performance plugin.
• Query Loop blocks that omit pagination or that nest queries until the archive times out.
• Editors padding every group until the content width is fiction.
• theme.json version mismatches after a WordPress update.
• Full site editing on multisite where one site's global styles leak into a process nobody documented.
• Caching full pages while the editor is used as a preview by staff on the same URL. Staff need DONOTCACHEPAGE behaviour or a separate preview host.

Migration from classic is a content move. I map PHP template parts to block templates one by one. I do not delete single.php until single.html has feature parity: comments, schema, and the share row if they still want it.

How to measure a block theme

Measure a block theme on the same URLs you already care about: home, PLP, PDP, a landing pattern, cart. Lab LCP and INP, field CrUX, and editor task time ("change the home hero image and a CTA"). If merchandisers need a developer for that task, the theme failed its brief even if Lighthouse is green.

I also count CSS bytes from /wp-content/themes and from core blocks on a cold PDP. A block theme that loads every variation of every core block is not "native therefore fast". Disable unused block styles in theme.json or via PHP.

Do not claim a sales lift from a theme rewrite unless that number is already on a published work case. The honest outputs are editability, fewer builder scripts, and a design system you can regress-test.

Related work on this site

Theme and WordPress product work is where this becomes concrete. Sophia Pro Theme is a multipurpose WordPress and WooCommerce theme I worked on as contract development on an agency team, with speed, SEO, and shop UX as the brief. BridgeWorx is a live ticketing site on WordPress and WooCommerce, where editors need event pages that stay on-brand without a developer for every show. A block theme with locked product/event templates and a small pattern set is the shape I want for that kind of site, with PHP left for tickets and cart.

FAQ

Are WordPress block themes required to use full site editing?

WordPress block themes are the path WordPress wants for full site editing, but you can still limit which templates are editable. A block theme does not mean every intern can rewrite checkout. You choose locks, roles, and which parts live in git.

Can WordPress block themes still use PHP templates?

WordPress block themes can include PHP for blocks, Woo, and fallbacks. They should not use PHP as a parallel layout engine for the same header the site editor already owns. Hybrid classic themes with theme.json are a different, valid step.

Do WordPress block themes replace a page builder?

WordPress block themes replace a page builder when you invest in patterns and training. They do not replace a builder on week one if the only alternative is core blocks with no kit. Budget the kit. Otherwise the builder comes back.

Are WordPress block themes faster than classic themes by default?

WordPress block themes are not faster by default. They can be faster when you drop builder JS and unused block CSS. They can be slower when the inserter is a plugin mall. Measure templates, then cut what you do not use.

Keep reading

• WordPress Interactivity API for storefront UI
• Gutenberg vs Elementor for site performance
• Sophia Pro Theme case study
• Bridgeworx case study
• More WordPress notes

Contact if you want this kind of work on a live store.