Development
Full-site editing in WordPress 6.x: what changed, what didn’t
Full-site editing isn't a switch you flip.
A client asked us last month whether their new site should be full-site editing or the old way, like those were two products on a shelf. You'd think it's a switch you flip and everything comes out faster and developer-free on the other side. It isn't.
Full-site editing is real, not experimental, not a beta, and as of the 6.x line it's the default path WordPress core is investing in. If a vendor tells you FSE isn't ready, that vendor stopped paying attention around 2022. Real is settled. What real actually buys you is the part worth slowing down for.
The boundary between design and code changed. In old WordPress the headers, footers, templates, and global colors all lived in PHP only a developer could touch. FSE pulls that into a visual editor, so your team edits the header the same way they edit a blog post.
What didn't change is the thing people quietly hoped would. FSE did not make the developer optional. A block theme that's maintainable, on-brand, and locked down so your team can't accidentally break the homepage is real engineering. The visual editor is the easy part. The system underneath it is still the job, exactly as much as it ever was.
Global styles are the quiet win.
Of everything FSE moved into the open, global styles earn their keep the most. Define your palette and type scale once in theme.json and it propagates everywhere, instead of getting copy-pasted into forty stylesheets that slowly drift apart. It's the same structured-versus-fused question behind ACF versus Gutenberg, one level up the stack.
That's the difference between a site that stays on-brand by design and one that stays on-brand by somebody remembering to. The visible editing got genuinely easier here. That part is true, and it's worth having.
Real and does-what-the-marketing-implies are two different things. The gap between them is the whole story.
Be skeptical of turn-it-on-and-lose-the-developer.
That's the version where the real engineering gets quietly skipped and you find out six months later, when the site drifts and nobody's left who understands the structure underneath.
Consistency mattering more than freedom is the case FSE was built for.
If your site is mostly content and the team wants routine edits, a clean block theme is a great fit, changing a headline or swapping an image without calling anyone, safely, without touching code. If the layout carries the brand and consistency matters most, you want FSE global styles underneath and a real content model on top, as long as someone builds the structure that enforces it.
Not sure which case your own site is? That's exactly the judgment call the redesign readiness scorecard is built to walk through.
The system underneath it is still the job, exactly as much as it ever was.