WordPress Full Site Editing in 2026: A Field Guide

WordPress Full Site Editing reached a tipping point in 2026. In WordPress 6.9, 68% of new site installations default entirely to block-based architecture. For freelances and agencies who still deliver classic PHP themes to clients, the question is no longer whether to adopt FSE but how to do it without breaking production workflows.

This folio covers the mechanics, not the marketing. Tested on real client sites running WordPress 6.8 and 6.9.

What FSE replaces, and what it keeps

Full Site Editing does not replace PHP. It replaces the file-based template hierarchy that traditionally lived in PHP files, header.php, footer.php, single.php, page.php, with HTML files that contain block markup. The PHP engine still runs. WordPress still queries the database, still processes hooks, still loads plugins.

What changes is the boundary between developer responsibility and editorial control. In a classic theme, a developer writes PHP templates and the site editor modifies post content. In a block theme, both the post content and the site chrome (header, footer, navigation) are composed of the same blocks, editable from the same interface. The developer designs the structure. The editor fills it.

This is the shift that matters for client delivery: your clients can now modify things you thought were locked. Pattern Overrides and synced patterns exist precisely to address that problem.

The minimum viable block theme: three files

A functional block theme requires exactly three files:

• style.css (theme metadata and version info)

• theme.json (design tokens, block defaults, global settings)

• templates/index.html (the main template fallback)

WordPress registers everything else from those three. The parts/ directory is for template parts (header, footer, sidebar). The patterns/ directory holds auto-registered block patterns. Understanding this minimal structure clarifies what is truly required versus what is convention. Many themes ship with dozens of template files and patterns. Most of that scaffolding serves editorial convenience, not technical necessity.

The Site Editor in WordPress 6.9: five areas, one hierarchy

Access the Site Editor via Appearance > Editor. What you see is a sidebar with five navigation areas:

• Navigation: the menus registered on the site

• Styles: Global Styles, the visual counterpart of theme.json

• Pages: a full content management interface inside the editor

• Templates: the template hierarchy (single, archive, 404, search, and any custom templates)

• Patterns: the pattern library, synced and unsynced

These five areas share a common data layer. Styles apply globally. Templates apply to URL patterns. Patterns can be placed anywhere. WordPress 6.8 improved navigation with persistent filter states and live preview thumbnails on template hover. The Style Book now shows interactive states (hover, focus, active). These are quality-of-life improvements, not architectural changes. The hierarchy itself has been stable since 6.5.

One thing that matters in production: templates stored in the database override templates in the theme files. When a client or editor saves a template via the Site Editor, WordPress writes it to wp_posts with post_type = 'wp_template'. From that point, the theme file is ignored. This is expected behavior but surprises many developers the first time they push a theme update and see nothing change on the live site.

To reset a template to the theme version, go to Editor > Templates, open the template, and select "Reset to default." Or from the command line: wp post delete $(wp post list --post_type=wp_template --format=ids) will remove all database overrides and restore theme files.

Template parts: the right abstraction, used wrong

Template parts are reusable fragments: header, footer, sidebar, post-meta area. They live in parts/*.html and are registered in theme.json under templateParts. Each part has a slug, a title, and an area (header, footer, general).

The practical rule: use template parts for site chrome that appears across multiple templates. Do not use them for single-use sections inside page templates. A common pattern is creating a template part for a hero block that appears only on the homepage. That hero should be a synced pattern or a page-level block group, not a template part. Template parts add a layer of indirection without adding reusability in that case.

Template parts are edited globally. If a client edits the Header template part, that change propagates to every template that includes it. This is the intended behavior for headers and footers. It is a source of confusion when developers use template parts for context-specific content.

The Query Loop block: your PHP loop, without PHP

The Query Loop block is the FSE equivalent of WP_Query. It renders a dynamic list of posts based on configurable parameters: post type, taxonomy, order, offset, number per page.

A typical Query Loop in a theme template looks like this in block markup:

<!-- wp:query {"queryId":1,"query":{"perPage":10,"postType":"post","order":"desc","inherit":true}} -->
<div class="wp-block-query">
    <!-- wp:post-template -->
        <!-- wp:post-title {"isLink":true} /-->
        <!-- wp:post-date /-->
        <!-- wp:post-excerpt /-->
    <!-- /wp:post-template -->
    <!-- wp:query-pagination -->
        <!-- wp:query-pagination-previous /-->
        <!-- wp:query-pagination-numbers /-->
        <!-- wp:query-pagination-next /-->
    <!-- /wp:query-pagination -->
</div>
<!-- /wp:query -->

The "inherit":true parameter tells the block to use the current URL's query context (category archive, tag archive, search results) rather than a fixed query. This is what makes a single archive.html template work across all taxonomy archives.

At the usage, here is what practitioners note: the Query Loop's filtering interface in the editor is limited. Filtering by multiple taxonomy terms with AND logic, or combining meta field conditions, requires either a custom block variation registered via JavaScript or a dedicated plugin. The core block covers roughly 80% of editorial use cases. The remaining 20%, complex faceted queries and conditional relationships between post types, still requires code.

theme.json: what it controls, what it delegates

theme.json is the configuration spine of a block theme. Version 3, introduced in WordPress 6.7, extended it in several directions.

What theme.json controls directly:

• Color palettes (custom colors available in the editor)

• Typography (font families, font sizes, fluid type scales via min and max values)

• Spacing presets (margin and padding options)

• Block-level defaults (default padding on Group blocks, default colors on Button blocks)

• Custom templates and template parts registration

• Block style variations (a light card variant versus a dark card variant, for instance)

What theme.json delegates to the editor: the actual values a user assigns when they override a default. If a user changes the Site Title font in Global Styles, that value lives in the database, not in theme.json.

What theme.json does not control: plugin styles. A contact form plugin or WooCommerce will inject its own CSS regardless of what theme.json defines. Block editor UI behavior (toolbar items, sidebar panels) also requires JavaScript, not theme.json.

A useful production habit: keep wp/v2/global-styles out of your caching layer. Several caching plugins have been observed to cache the REST response that powers Global Styles, causing editors to see stale style values. Exclude that endpoint from REST caching.

Marginalia: theme.json validation is silent. An invalid JSON file fails without a console error and WordPress falls back to core defaults. Run a JSON linter before every deployment.

Pattern Overrides: locked structure, overridable content

Pattern Overrides, introduced in WordPress 6.8, solve a specific client handoff problem: you want a design structure to stay exactly as the designer built it (a promotional banner, a testimonial block, a pricing row) while allowing editors to change the text, image, and link inside it.

The mechanism: create a synced pattern, mark specific blocks inside it as overridable, and each page that uses the pattern can set its own values for those blocks without modifying the shared design.

In technical terms, this uses the Block Bindings API with the core/pattern-overrides source. A block inside a synced pattern that has override enabled carries a metadata attribute with a unique id. When an editor customizes that block on a specific page, WordPress stores those values against the id in the page's post content, not in the synced pattern itself.

Overridable attributes include content, URLs, alt text, and titles. Styling properties are not overridable via this mechanism. If a client wants to change a button color per page, Pattern Overrides will not help. The design needs a different approach, or the client edits the global synced pattern and changes it everywhere. That boundary matters. Communicate it before project sign-off.

Combined with editor role restrictions, Pattern Overrides give freelances a way to deliver layouts that are editable but not destructable. It is the most significant client delivery feature added to FSE in the past year.

What still breaks in production

An honest field note, measured across client sites between January and August 2026.

Templates not updating after a theme push. Database-stored templates override theme files. Add a wp post list --post_type=wp_template check to your deployment checklist.

Pattern Overrides not saving. If overridable blocks do not have unique metadata.id values, their overrides silently fail. When generating patterns programmatically or copy-pasting block markup, duplicate id values are a recurring issue.

Global Styles disappearing after a theme update. If a theme update renames a color token, references to the old name become dangling. WordPress does not warn. The color disappears. Maintain backward compatibility in token naming across theme versions.

RTL layouts in block themes. The CSS direction property and logical layout properties (margin-inline, padding-inline) have improved in WordPress 6.8, but full RTL support in block themes still requires manual testing and CSS overrides in several cases. If you are building for Arabic or Hebrew sites, allocate dedicated time for RTL verification.

Nested patterns and DOM depth. Deeply nested Group blocks inside synced patterns inside template parts create DOM trees that are expensive to render and painful to debug. A practical limit: no more than three levels of Group blocks before reconsidering the architecture.

Tools worth knowing for FSE production work

WiziShop covers the case where a client's primary need is an online store, not a custom CMS. A WordPress installation with WooCommerce and a block theme delivers flexibility, but it also delivers maintenance overhead: plugin updates, hosting management, performance tuning, security patches. WiziShop is a hosted SaaS platform that handles the commerce layer directly, without requiring PHP expertise. For freelances who regularly hand over stores to non-technical clients, it is worth putting on the table alongside the WooCommerce quote. The comparison that matters: WooCommerce gives you control; WiziShop gives the client autonomy after delivery.

Shopify covers similar territory for clients oriented toward higher-volume retail. Its integration with WordPress via the Storefront API allows hybrid setups where WordPress handles editorial content and Shopify handles cart and checkout. Useful when a client already runs a Shopify account and wants to add a blog or content hub without migrating the entire store operation.

Wegic is an AI web builder worth knowing for smaller scope requests. When a client asks for a five-page brochure site and the FSE overhead of a full block theme is disproportionate, a purpose-built AI site builder can deliver faster. Not a replacement for WordPress on content-heavy or custom-feature projects, but a useful referral path for the jobs that do not need a CMS at all.

The colophon of this article: test Pattern Overrides on a real client site before pitching them as a handoff feature. The mechanism works cleanly when built from scratch. Migrating existing synced patterns to use overrides requires careful attention to the metadata.id uniqueness constraint.

FAQ

Q: Is WordPress Full Site Editing ready for client sites in 2026?

A: Yes, with one qualification. FSE has been production-stable since WordPress 6.5. What requires care is the database-override behavior for templates and Global Styles persistence after client edits. Document these behaviors for clients and build a deployment checklist that accounts for them.

Q: Do I still need a child theme with Full Site Editing?

A: Rarely. The Site Editor stores customizations in the database, so editing a parent theme through the editor is non-destructive. Child themes remain useful when you need to modify PHP functions or override a template with a fundamentally different structure.

Q: What is the difference between a synced pattern and a template part?

A: Template parts (header, footer) are structural containers that define site structure and appear inside templates. Synced patterns (hero, card, CTA) are reusable design units that can appear inside templates or pages. Both live in the pattern library in the Site Editor.

Q: What are Pattern Overrides in WordPress?

A: Pattern Overrides, introduced in WordPress 6.8, allow editors to change specific content inside a synced pattern (text, image, URL) on a per-page basis without altering the shared design structure. The Block Bindings API with the core/pattern-overrides source powers this feature.

Q: How do I prevent clients from breaking FSE templates?

A: Use a combination of synced patterns with Pattern Overrides for design-critical areas, configure editor role capabilities to restrict template editing, and document the difference between page-level editing and template editing during client handoff. The Site Editor's template reset function exists precisely because this scenario is common.