WordPress · 2026-07-02
Full Site Editing Wasn't a Technical Transition. It Was a Mental One.
For years, WordPress development operated under an implicit contract.
Content lived inside pages.
Themes controlled presentation.
Widgets occupied designated spaces.
Menus existed independently.
Templates were developer territory.
Editors changed text. Developers changed structure.
Over time, page builders emerged because those boundaries became increasingly difficult for editors to navigate. Clients wanted more flexibility, agencies wanted greater consistency, and developers found themselves creating custom solutions simply to bridge the gap between content and design.
Full Site Editing represents WordPress's attempt to rethink that entire model.
Rather than layering additional tools onto an increasingly fragmented system, Full Site Editing aims to bring content, layout, templates, and design language together into a unified experience.
Technically, it succeeds more often than people give it credit for.
Culturally, however, it asks users to abandon assumptions that have existed for more than a decade.
What Actually Changed
Discussions about Full Site Editing often become lists of features: block themes, patterns, templates, theme.json. While those pieces matter, understanding the problems they solve is more useful than memorizing definitions.
Block themes fundamentally change who controls structure.
In classic WordPress, altering a header, footer, archive template, or search layout usually required touching theme files or involving a developer. Even organizations with technically capable editors often depended on development resources for relatively small visual adjustments.
Block themes turn those components into editable systems.
Headers become reusable objects.
Footers become editable experiences.
Archive layouts can evolve without custom PHP templates.
The goal is not necessarily to eliminate developers from the process, but to reduce the number of times developers are required for changes that are fundamentally editorial.
Patterns solve a different problem.
Agencies have wrestled with the same challenge for years:
How do you provide flexibility without allowing every page to become entirely unique?
Patterns introduce structure without imposing rigidity.
Editors gain the ability to assemble content from approved building blocks while maintaining consistency across an entire site. Instead of every page becoming a bespoke composition, organizations can establish visual systems that scale.
This becomes particularly valuable in environments with multiple contributors, changing staff, or long-lived websites where maintaining design cohesion matters.
Then there is <code>theme.json</code>.
At first glance, it appears to be little more than a configuration file.
In practice, it represents a significant shift in how WordPress approaches design.
Typography settings, spacing rules, color palettes, layout constraints, and visual defaults become centralized decisions rather than scattered CSS overrides accumulated over years of incremental changes.
For organizations already thinking in terms of design systems, <code>theme.json</code> feels familiar.
For teams accustomed to solving presentation issues one page at a time, it can feel like a very different way of working.
The Difficult Part
Ironically, the hardest aspect of Full Site Editing has not been technical.
Developers can learn templates.
Designers can understand patterns.
Site administrators can eventually become comfortable with global styles.
What proves more difficult is changing expectations.
Transitioning assumptions is harder than transitioning technology.
Many clients spent years learning a specific workflow.
Edit page.
Adjust layout.
Publish.
Everything happened at the page level.
Full Site Editing introduces distinctions between page content, templates, template parts, patterns, global styles, and site-wide settings.
These concepts are logical.
They are also unfamiliar.
The friction surrounding Full Site Editing often has less to do with capability and more to do with cognitive models reinforced over many years.
People naturally ask:
"Why did changing the header affect every page?"
"Why is this block locked?"
"Why can't I edit this section directly?"
Those questions do not indicate failure.
They indicate that WordPress is asking users to think more systemically.
One thing I did not anticipate was how many decisions Full Site Editing pushes back toward developers.
In classic WordPress themes, editorial boundaries were often implicit.
Clients could edit content.
Developers controlled templates.
The separation was understood, even if it was sometimes frustrating.
With Full Site Editing, those boundaries become configurable.
Should editors be allowed to modify the header template?
Should they be able to change typography?
Can they create new color combinations?
Can they rearrange reusable patterns?
Should they have access to template parts at all?
Those choices now exist.
And every decision changes the editing experience.
On one recent Full Site Editing implementation, we spent considerably more time discussing permissions than templates.
The technical work itself was straightforward.
The harder question was deciding what editors actually needed access to.
Should someone be able to update a phone number in the header? Absolutely.
Should they be able to redesign the header itself? Probably not.
Typography controls? Color palettes? Template parts? Pattern creation?
Those decisions become part of the implementation process.
The objective wasn't limiting editors. It was reducing opportunities for inconsistency to emerge over time.
In practice, the project became less about building pages and more about designing an editing experience.
For organizations with technically comfortable teams, that flexibility can be powerful.
For organizations that update their website a few times each year, it can feel overwhelming.
Many clients do not want to understand global styles, template parts, pattern overrides, or design systems.
They want to update a phone number, swap out a hero image, and publish a new announcement.
In practice, implementing Full Site Editing often means spending more time creating guardrails.
Locking template structures.
Defining approved color palettes.
Restricting typography options.
Building reusable patterns.
Removing unnecessary controls.
Creating an editorial experience that feels simple, even when the underlying architecture has become significantly more sophisticated.
Ironically, some of the best Full Site Editing implementations may be the ones where clients barely realize they are using Full Site Editing at all.
The technology becomes successful when editors feel less empowered to experiment and more empowered to accomplish the tasks they actually need to perform.
What Improved
Despite the adjustment period, Full Site Editing solves several long-standing issues that WordPress developers have encountered for years.
Consistency improves.
Reusable structures become easier to maintain.
Design systems become more accessible to non-developers.
Organizations gain the ability to evolve layouts without rebuilding entire themes.
For developers, it also reduces a category of repetitive work that historically consumed time without adding significant value.
Small header updates.
Footer changes.
Archive modifications.
Minor layout adjustments.
Many of these requests can now move closer to the editorial side of the organization.
In practice, teams can spend less time responding to requests like:
"Can you update the footer phone number?"
or
"We changed office locations. Can you update the address everywhere?"
and more time working on integrations, accessibility improvements, performance issues, content architecture, and functionality that genuinely requires development effort.
That shift changes where technical teams are able to spend their energy.
There is still a place for custom development.
There always will be.
But Full Site Editing changes where development effort is best invested.
Practical Lessons
After working through both traditional WordPress implementations and newer Full Site Editing environments, a few observations have become increasingly clear.
Full Site Editing is not simply a replacement for page builders.
It is a different philosophy.
Organizations already thinking in reusable systems often thrive within it.
Organizations expecting unlimited page-level control may find the transition frustrating.
Neither approach is inherently wrong.
They simply prioritize different goals.
In practice, successful adoption often depends less on technical sophistication and more on organizational mindset.
Teams that value consistency, repeatability, and governance tend to see benefits quickly.
Teams seeking maximum local flexibility may continue preferring other solutions.
That is less an indictment of Full Site Editing and more a reminder that tools succeed when they align with how people already work.
Looking Back
Full Site Editing feels less like a feature release and more like WordPress redefining its own identity.
The platform spent years evolving through plugins, builders, widgets, custom fields, and conventions layered on top of one another.
Eventually, the ecosystem became powerful but fragmented.
Full Site Editing appears to be an attempt to bring those ideas back into a coherent framework.
Whether people embrace it or resist it often depends on which assumptions they are being asked to leave behind.
The technology itself is not particularly difficult.
The challenge is learning to think differently about what a website actually is.
And in many ways, that has always been the hardest part of any major transition.