WordPress Full Site Editing (FSE) represents one of the most significant shifts in the platform’s history. The promise is compelling: a unified, block-based editing experience that gives users complete visual control over every part of their site, including headers, footers, templates, and global styles, without writing a line of code or touching a PHP file.
We recognise the ambition behind FSE, and we support its direction. But supporting a direction is not the same as unconditionally adopting every implementation of it, particularly when that implementation is still maturing, and particularly when the alternative we offer already delivers on the same promise, and in several important respects, exceeds it.
This document sets out our position on core FSE block themes, why GeneratePress has not adopted that model today, what we offer instead, and where we are heading.
What FSE Promises
The case for FSE block themes is well established:
- A single unified editing interface for the entire site
- Global style management via theme.json for colours, typography, and spacing
- Visual template editing without PHP knowledge
- Performance advantages over legacy page builders through leaner HTML, CSS and JS delivery
- A future-proof foundation aligned with WordPress core development
These are real benefits. For many users, FSE block themes represent a genuine step forward from the classic theme model, and from the bloated page builder ecosystem that grew up around WordPress’s limitations.
We do not dispute any of this. What we dispute is the assumption that adopting a core block theme is the only, or the best, way to realise these benefits.
The Reality of Core FSE Today
Despite significant progress, core FSE block themes carry a number of well-documented limitations that make wholesale adoption a poor fit for the users and developers who rely on GeneratePress.
Styling Capability Is Fundamentally Constrained
The Site Editor and theme.json expose a curated, intentionally limited subset of CSS. This implementation is conservative by design, given that WordPress core must serve the broadest possible audience. In practice, developers routinely hit a ceiling and are forced to resort to custom CSS workarounds, undermining the no-code promise FSE makes.
GenerateBlocks takes the opposite approach. Its styles builder already covers an extensive range of CSS properties, and a forthcoming update will extend this to 100% of current and future CSS with no artificial ceiling imposed by what core chooses to expose.
This styling capability is applied across three dimensions simultaneously: responsively at any breakpoint via media and container queries; fluidly through native CSS math functions including calc() and clamp(), and with selector-based precision, targeting any child element, pseudo-element, or state within a block’s output.
This is not an incremental improvement over core. It is a categorically different level of capability, one that core FSE cannot match given its design philosophy, and one that makes dropping into custom CSS a genuine exception rather than a regular necessity.
HTML Output Is Locked to Block Structure
Core FSE is constrained to the HTML output of its registered blocks. Breaking out of that markup structure for semantic, accessibility, or layout reasons requires building custom blocks, which is a significant development overhead. GenerateBlocks removes this constraint entirely by allowing any HTML tag of any kind to be output directly. Any semantic structure, any element, any attribute is achievable within the block editor.
Dynamic Content and Conditional Logic
Core FSE does provide some dynamic data handling. The Query Loop block covers basic post listing, and theme blocks such as Post Title, Post Content, and Featured Image allow dynamic data to be surfaced in templates. For straightforward use cases, this is functional.
GenerateBlocks Pro goes considerably further. Its query system supports advanced parameters, custom post types, meta fields, and relational queries that the core Query Loop does not accommodate. More significantly, dynamic data in GenerateBlocks is not limited to designated output blocks. Dynamic tags allow live data to be inserted directly into block content and HTML attributes anywhere in the editing interface, meaning a value from post meta, site identity, or a custom field can populate text, a URL, or any other attribute within our blocks. This flexibility is absent from core FSE, where dynamic data remains largely confined to its predefined theme block outputs.
Conditional logic, such as showing or hiding content based on post meta, user state, taxonomy, or custom fields, is also absent from core FSE without third-party plugins. GenerateBlocks Pro provides this natively through its Conditions system, within the same coherent editing environment.
What GeneratePress Offers Today
The GeneratePress and GenerateBlocks combination is not a compromise pending an FSE migration. It is a fully realised, hybrid site-building system that delivers on every meaningful promise of FSE while addressing the limitations core FSE has yet to resolve.
- Complete CSS coverage: an extensive and growing styles builder, with 100% CSS coverage arriving imminently, applied fluidly with math functions, responsively at any breakpoint, and with selector-level precision
- Unrestricted HTML output: any tag, any structure, without custom block development
- Native dynamic content: dynamic tags and post meta integration without additional plugins
- Conditional templating: the GB Pro Conditions system allows any block, template, overlay or menu to be shown or hidden based on contextual rules, applied site-wide from a central interface
- Global Styles: reusable style classes applied consistently across the site, with a single point of change
- Production-ready code output: CSS compiled and minified at build time, static HTML output with no front-end runtime dependencies
The Performance Question
Performance is consistently cited as one of the primary benefits of adopting core FSE block themes. However, that argument is made in the context of bloated classic themes and heavy page builders, not against a combination like GeneratePress and GenerateBlocks.
GeneratePress is recognised as one of the most performant WordPress themes. Its minimal footprint and build-time CSS compilation set a high baseline. GenerateBlocks compounds this by delivering production-ready HTML and CSS with no front-end runtime dependencies. With similar characteristics, the performance case for moving to a block theme simply does not apply here.
Why Not a GP Block Theme with GenerateBlocks?
A reasonable question follows from the above: if the limitations lie in core FSE’s styling and dynamic content capabilities, why not combine a GeneratePress block theme with GenerateBlocks? GenerateBlocks would handle the design and layout, while the block theme provides the FSE template layer. On the surface, this appears to resolve the tension.
In practice, it creates new problems that the combination does not solve.
A block theme imposes a design system that GB-built sites do not need. When a block theme is active, WordPress automatically loads its global styles and design system output. This is not optional. For sites built entirely with GenerateBlocks, that entire layer is redundant, contributing no value to the design while adding CSS to every page load and introducing a potential source of specificity conflicts with GenerateBlocks’ own compiled styles.
The Site Editor’s template capabilities are significantly more limited than GP’s current templating approach, and HTML templates introduce a maintenance liability. Block theme templates are defined in HTML files that live within the theme. When the theme updates, those templates can break or diverge from what the site expects, in ways that are outside the site owner’s control and difficult to anticipate. GP’s templating approach keeps that control firmly with the builder, not with the theme update cycle.
It surrenders GP’s ability to be selective about what it adopts from core. Today, GeneratePress can evaluate each WordPress feature on its merits, promoting what genuinely serves users, such as Patterns and Synced Patterns, and declining what does not. Adopting a block theme as the foundational layer hands structural control back to WordPress core’s direction and release cycle. That selectivity is a meaningful product strength, and one that a block theme dependency would compromise.
Where We Are Heading
Our position is not one of resistance to FSE. It is one of deliberate, considered progress toward a purpose-built site editing experience that does not inherit the limitations of core’s implementation.
We are actively developing a next-generation architecture that will bring together improved templating, a unified design management system, and a radically simplified theme foundation, all built around the GenerateBlocks editing experience that our users already know.
This evolution will deliver a genuine full-site editing experience: complete, coherent, fast, and stable. It will arrive when it meets our standards, not because it follows a trend.
We believe the best version of FSE for GeneratePress users is one we build ourselves, on our terms with a commitment to empowering developer capabilities, with our tooling, and with the performance and stability our users expect.
Conclusion
WordPress FSE is the right direction. Core block themes are one implementation of that direction, and one that remains constrained in styling capability, limited in HTML flexibility, and unable to match the dynamic content and performance output that GeneratePress and GenerateBlocks already deliver.
In the areas that matter most to developers and performance-focused builders, including CSS coverage, responsive control, HTML flexibility, dynamic content, and raw output speed, the GP and GB combination already goes beyond what core block themes offer.
We are not standing still. We are building toward something better. And we will get there on our own terms with our customers’ needs as a primary focus.
I absolutely love this. Well stated.
Keep doing what you are doing.
Thanks for the support, Dave, and for using GeneratePress.
Good read. Happy to learn that GeneratePress is building its own FSE 😈
Love this.
Quick question — does this approach still work if the conditions are slightly different? I’d love to see a follow-up on that.
Could you clarify which specific conditions you’re referring to, and how they might differ from what we outlined in the post? We’d be happy to address it directly or even consider a follow-up if it’s a common scenario.
I really like the detail and careful consideration going in here.
My concern for the Generate ecosystem is what happens if and when WordPress start deprecating the older, ‘legacy’ theming functions in favour of FSE? Will that not bring additional overhead to manage this? Is there not a danger that this could lead to a dead end eventually?
A vast majority of WordPress sites would have to be FSE-first for WordPress to make this kind of change. As mentioned, we will be watching this space closely and adjusting as needed. But from where we are now and the foreseeable future, we’re confident this is the right path for our users. Thank you for the comment, Ray!
It’s certainly a risky decision, but I’m glad that’s your choice: not to compromise on the principles that have underpinned GeneratePress from the start, in the face of an FSE project that is, at the very least, questionable in its approach.
Thank you.
Thanks for the comment, Alvaro. We’re continuing to watch development, but we need to put our customers’ needs first. Thanks for the feedback.