Full Site Editing launched in WordPress 5.9 in January 2022. Four years later, with WordPress 7.0 on the horizon, the honest question is: how much of it actually works in production? Not in demos. Not in the “Ten” theme. In real client sites, real WooCommerce stores, real agencies shipping work on deadlines.
The answer is complicated. Some parts of FSE are now genuinely excellent, better than classic themes in measurable, practical ways. Other parts are still rough in ways that will surprise you on a real project. And a few things are still broken enough that using them in production is a mistake you will be fixing for months.
This is that honest assessment. No marketing, no hype, no “FSE is the future so you should learn it” hand-waving. Just what works, what does not, and what changed in WP 7.0 that is actually worth paying attention to.
What “Full Site Editing” Actually Means in 2026
FSE is not one feature, it is a stack of features that shipped incrementally over four WordPress releases. Understanding which layer you are talking about matters because the maturity varies significantly across them:
- Block themes, themes built entirely with HTML templates and
theme.jsoninstead of PHP templates andfunctions.php. Shipped in WP 5.9. Now mature. - Site Editor, the admin interface for editing templates, template parts, and global styles. Shipped in WP 5.9. Still improving but usable.
- Global Styles, the design token system in
theme.jsonthat controls typography, colors, spacing, and per-block defaults across the whole site. Mature and excellent. - Style Variations, alternate design configurations a user can switch between without changing the theme. Mature and underused.
- Pattern library, registered block patterns (layouts) that users can insert into any post or page. Mature.
- Pattern Overrides, the ability to override specific blocks within a synced pattern per-instance. New in WordPress 7.0. Genuinely useful.
The core of the FSE stack, block themes, theme.json, Global Styles, is production-ready. The edges, WooCommerce integration, third-party plugin compatibility, multisite management, are still catching up.
What Is Finally Worth Using in 2026
theme.json, Now Genuinely Excellent
The theme.json design token system is the best part of FSE and the most underappreciated. In classic themes, design consistency requires cascading CSS overrides, hardcoded hex values across multiple stylesheets, and hoping nothing breaks across WordPress updates. theme.json replaces all of that with a single structured file that defines your typography scale, color palette, spacing system, and per-block defaults in one place.
The output is semantic CSS custom properties that WordPress generates from your definitions. Change --wp--preset--color--primary in one place and every block that references it updates. Style a Heading block globally in theme.json and every Heading block across the entire site inherits it, with per-instance overrides still possible. This is proper design system thinking applied to CMS themes, and it works well in production.
The same design system principles that made shadcn/ui successful in the JavaScript ecosystem translate directly to theme.json. Semantic token names, owned implementations, style variations, the architecture supports all of it.
Template Parts, Production Ready, Actually Better Than PHP
Headers and footers as template parts in the Site Editor are now production-ready. Clients can edit their navigation, update a phone number in the footer, or change the call-to-action in the header, without touching the theme files or the Customizer. The changes save directly to the database as user customizations on top of the theme defaults.
This is a genuine improvement over classic themes for agency work. The old pattern of “client wants to change the header CTA, developer makes a PHP change, pushes to staging, client approves, deploys to production” is replaced by “client edits the template part directly.” That reduces round-trips on maintenance work considerably.
The template parts system has matured enough that complex header layouts, sticky headers, mega menus, conditional display, are achievable without custom PHP, though some advanced patterns still benefit from a thin PHP layer.
Pattern Library, The Best Way to Ship Reusable Layouts
Registered block patterns are the right way to ship reusable page sections in 2026. A pattern library in your theme gives users access to tested, styled layouts they can insert anywhere, hero sections, testimonial grids, pricing tables, feature rows. Each instance is an independent copy they can edit without affecting other instances.
Pair this with Pattern Overrides in WordPress 7.0 and you get the best of both worlds: synced patterns for layouts that must stay consistent site-wide, with overrides on the content blocks (headings, images) that vary per instance. This is the model that makes block themes genuinely competitive with page builders for client sites.
Style Variations, Underused But Excellent for Multi-Brand Work
Style variations let you ship a theme with multiple visual designs, a light mode, a dark mode, a high-contrast accessibility variation, a brand-specific palette, all switchable by the user in the Site Editor without any CSS overrides. The variation just remaps the theme.json token values to different concrete values.
For agencies building themes used across multiple client sites, this is the right architecture. One theme, many palettes, zero CSS overrides. The practical advantages over classic themes are clearest here, a classic theme would need a child theme or a Customizer mess to achieve what a style variation does in 30 lines of JSON.
What Has Improved But Is Still Rough
WooCommerce FSE Support, Better, Not Complete
WooCommerce launched its own block-based cart, checkout, and product templates starting with version 8.x, and the experience has improved significantly. Basic product archives, single product pages, and the cart/checkout flow now work well in block themes without the classic template fallback that was necessary in 2023.
What is still rough: complex product filtering (faceted search), subscription product templates, and the mini-cart in the header. Plugins like WooCommerce Product Filters and YITH have released block-compatible versions, but compatibility with FSE-specific features like style variations and custom template parts is inconsistent. If your WooCommerce project relies heavily on third-party WooCommerce plugins, verify each one’s block compatibility before committing to a block theme.
Third-Party Plugin Blocks, Quality Varies Widely
Every major plugin now ships blocks, but the quality varies wildly. Well-resourced plugins, Gravity Forms, WPForms, Jetpack, have invested properly in block development and their blocks respect theme.json color and typography settings. Smaller plugins often ship blocks that hardcode styles, break inside Group blocks, or ignore the spacing scale entirely.
The practical test: paste the plugin’s block inside a styled Group block that uses a custom palette color as background. Does the block’s typography inherit the theme’s text color? Does its spacing respect your theme.json spacing scale? Most blocks fail at least one of these. This is not a blocker for using FSE, but it is a QA step you need to run on every third-party plugin before launch.
Font Management, Improved But Finicky
WordPress 6.5 added a font library directly in the Site Editor, allowing users to install and manage fonts without touching theme files. This solved a real usability problem. In practice, the font library works well for adding Google Fonts but has edge cases with custom font files (WOFF2 uploads), fonts with many weights, and variable fonts. For developer-controlled theme typography, defining fonts directly in theme.json and bundling WOFF2 files in the theme is still more reliable than the font library.
What Is Still Genuinely Broken
Custom Fields in Templates, Use ACF Blocks Instead
Displaying custom field data in block theme templates is still painful. The Block Bindings API (added in WP 6.5) allows binding core block attributes to custom fields, but it supports only a subset of block attributes, image url, paragraph content, heading content, and button url. Complex custom field displays, repeater fields, relationship fields, conditional displays based on field values, are not supported natively.
For projects that depend heavily on Advanced Custom Fields or Meta Box, the practical path is still ACF Blocks (React-based blocks that render ACF field data) rather than trying to build a pure block theme solution. This is not going to change in WP 7.0. The Block Bindings API will expand, but repeater fields are not on the near-term roadmap.
Multisite, Template Management Is Still Manual
Multisite networks using block themes face a problem: there is no way to push template or template part changes from a parent theme to all network sites simultaneously. Each site maintains its own template customizations in the database. If you update the header template part in the theme and a site has previously customized it, the site’s customization takes precedence, the update is silently ignored.
Classic themes handled this with PHP template files that just loaded across all sites. Block themes that store customizations in the database break this mental model. For multisite networks, you either need to avoid letting site administrators customize templates at all (which removes the main FSE benefit), or you need to write custom tooling to push template resets across the network. Neither option is good. Multisite + FSE is still an unsolved architecture problem.
Revision History for Templates, Limited and Confusing
WordPress stores template customizations as custom post type entries, which means they participate in the revision system, but the revision UI in the Site Editor is minimal. You can see a list of revisions and restore them, but there is no diff view, no way to compare two revisions visually, and no way to see what changed between them. For client sites where multiple people edit templates, this is a real practical problem. Classic themes with version-controlled PHP files were actually better here.
The Site Editor UX in 2026: Better, But Not Client-Friendly by Default
The Site Editor interface has improved substantially since its awkward debut in WordPress 5.9. The left-side navigation panel introduced in WordPress 6.4 organizes Templates, Template Parts, Patterns, Styles, and Pages into a coherent structure. The block inserter is faster. Drag-and-drop between sections works more reliably. Undo/redo has become more stable across complex edits.
That said, the Site Editor is not a client-facing tool by default. The full Site Editor gives clients access to every template on the site, global styles, all template parts, the pattern library, custom CSS. Most clients should not have all of that. The responsible setup for client handoff is restricting Site Editor access to specific capabilities using edit_theme_options capability checks, or using plugins like Editor Role that limit which panels are visible.
The other ongoing UX issue is visual consistency between the Site Editor and the post editor. Blocks that look one way in the post editor can render differently in the Site Editor depending on how template context affects inherited styles. This is a known issue with no clean fix, the two editors apply styles differently because they are rendering in different DOM contexts. For developers, the practical answer is always preview in the Site Editor before handing off to a client, not just in the post editor.
Developer Workflow: How FSE Changes the Build Process
Building a block theme looks different from building a classic theme. The shift is not just technical, it is a different mental model for how themes are structured and how changes flow from development to production.
In a classic theme, your PHP templates are the source of truth. You edit them in your code editor, commit to git, deploy. The Customizer and widgets store small user customizations in the database, but the structural templates stay in code.
In a block theme, templates can exist in two places: in your theme’s templates/ directory (the code-layer default), or in the database as a user customization that overrides the theme default. This duality creates a practical problem for version-controlled development: if a client edits a template in the Site Editor, that change lives in their database, not in your git repository. Syncing it back to code requires exporting the template HTML and committing it, a step that is easy to forget.
The workflow that avoids this problem: use the create-block-theme plugin (available in the WordPress plugin directory) to export Site Editor customizations back to theme files. This plugin adds an “Export” option to the Site Editor that packages all database-stored templates back into a downloadable theme zip. For agencies, building this export step into the handoff process is essential for keeping the theme repository as the actual source of truth rather than the client’s database.
The other workflow change is theming with theme.json rather than CSS. In a classic theme, you write CSS to apply styles. In a block theme, you define tokens in theme.json and let WordPress generate the CSS. This is better for maintainability and global consistency, but it requires learning which CSS properties are controllable via theme.json and which still need a style.css override. The answer in 2026: most layout and typography properties are theme.json-controllable; complex pseudo-element styles, animations, and some advanced hover states still need style.css.
What WordPress 7.0 Fixes (And What It Does Not)
WordPress 7.0 ships two FSE improvements that matter for production use. The first is Pattern Overrides, already covered above, and genuinely useful. The second is improvements to the Site Editor’s template part management interface, with clearer visual indicators of which templates are using the theme default versus a site-specific customization.
What WP 7.0 does not fix: multisite template management, the Block Bindings API coverage gap, or the third-party plugin block quality problem. The Connectors API, the headline feature of 7.0 for plugin developers, does not directly affect the FSE experience for theme developers or end users. It is a plugin-to-agent API, not a theme API.
Should You Use FSE for Your Next Project?
Here is the honest decision framework. FSE is the right choice for some projects and the wrong choice for others in 2026. The signals:
| Project Type | FSE Decision | Reason |
|---|---|---|
| Marketing site, portfolio, brochure | Yes, FSE is better | theme.json + pattern library outperforms classic themes on design system maintainability |
| Blog or editorial site | Yes, FSE is better | Site Editor template management works well; client editing is simplified |
| Simple WooCommerce store | Yes, with caveats | Block cart/checkout is production-ready; verify all WooCommerce plugin compatibility first |
| Complex WooCommerce (subscriptions, advanced filtering) | Not yet | Third-party plugin compatibility is inconsistent; test extensively before committing |
| Heavy ACF / custom fields site | Not yet | Block Bindings API coverage is too limited; ACF Blocks are still the better path |
| WordPress Multisite network | No, wait | Template management in Multisite is unsolved; stick with classic themes |
| LMS / membership site | Depends on plugins | LearnDash and MemberPress have block-compatible versions; verify compatibility first |
The migration path is also worth considering. If you are moving an existing classic theme site to FSE, the migration guide covers the full process, including how to handle existing widget areas, customizer settings, and PHP template overrides. It is doable for most sites, but it is a real project, not an afternoon task.
Frequently Asked Questions
Is Full Site Editing stable enough for client sites in 2026?
For marketing sites, blogs, and simple WooCommerce stores: yes. The core FSE stack, block themes, theme.json, Global Styles, template parts, has been stable across multiple WordPress versions and is production-ready. The remaining instability is at the edges: complex WooCommerce setups, heavy ACF usage, and Multisite. For those project types, classic themes remain the safer choice until the specific compatibility gaps are addressed.
Will classic themes still work after WordPress 7.0?
Yes. WordPress has been explicit that classic theme support is not going away. The “classic” block theme introduced in recent WordPress versions (which is actually a block theme with backward-compatible template fallbacks) exists precisely to bridge the gap. Classic PHP themes, including child themes of classic themes, will continue to work. The transition to block themes is optional and incremental, WordPress is not forcing it.
Can clients edit FSE sites without breaking things?
With the right setup, yes. The key discipline is using synced patterns with Pattern Overrides for layouts that should stay structurally consistent. This gives clients a designated area to change content, the heading text, the image, the CTA, while locking the layout structure so they cannot accidentally delete the section or break the columns. Without Pattern Overrides, giving clients Site Editor access to templates is risky. With them, it is manageable. This is the biggest practical improvement in WordPress 7.0 for agency projects.
Does using FSE affect WordPress site performance?
Block themes typically load less CSS than classic themes because theme.json generates only the custom properties actually defined in your token set, rather than loading a full classic stylesheet. Core blocks are also more reliably optimized for Core Web Vitals than third-party page builder elements. That said, performance ultimately depends more on your hosting, caching configuration, and image handling than on whether you use FSE. A badly optimized block theme will still be slow. A well-optimized block theme will generally score better on Lighthouse than a comparable classic theme because of leaner CSS output and better HTML structure from core blocks.
The Honest Bottom Line
FSE in 2026 is not a complete replacement for classic themes, not yet. It is a production-ready architecture for a specific class of projects, and a still-maturing architecture for others. The sites where FSE is unambiguously the better choice today are marketing sites, editorial sites, and standard WooCommerce stores. The sites where classic themes remain the right call are multisite networks, ACF-heavy applications, and WooCommerce projects with complex third-party plugin dependencies.
What is different in 2026 versus 2023 is that the question is no longer “is FSE ready?” for most projects, it is. The question is whether your specific project’s requirements hit one of the remaining rough edges. Run the decision table above, check your plugin stack for block compatibility, and make a deliberate choice rather than defaulting to either “FSE because it’s new” or “classic theme because it’s safe.”
If you are starting a new block theme project, the right foundation is semantic token naming in theme.json, a pattern library built with Pattern Overrides in mind, and style variations from day one. That combination, detailed in the theme.json deep dive and the design system principles guide, is the FSE architecture that will still be maintainable in three years, regardless of what changes between WordPress 7.0 and whatever comes after it.