When WordPress 5.9 landed, the part that interested me most was not the announcement itself, it was the change in responsibility between the theme and the editor. WordPress had been moving in this direction for a while, however full site editing made the direction much harder to ignore. Headers, footers, templates and global styles were no longer sitting completely outside the block editor. The question for me became less about whether the feature was impressive and more about how it would affect the way I structure a real theme.
At the time, most client projects I worked on still depended on traditional themes, custom templates and a fairly controlled editing experience. That approach had advantages because it gave the build a clear shape. Editors could change the content they needed to change, but they were not expected to understand every layout decision behind the website. Full site editing challenged that balance, because it moved more of the page structure into WordPress itself.
Starting With The Existing Theme Problem
The first thing I wanted to understand was what problem full site editing was actually solving. In a traditional WordPress theme, a lot of design decisions are locked inside PHP templates, CSS and theme options. That can be good for consistency, but it also means small structural changes often need a developer. A client might only want to adjust a call-to-action section or change a footer layout, but the answer could still involve template work.
I have always been cautious about giving editors too much layout freedom without a clear system around it. A website can lose consistency quickly if every page becomes a design surface. My concern with full site editing was not that editors could change more things. My concern was whether the theme could still guide those decisions properly, so the website remained coherent after a few months of real use.
That changed how I looked at the feature. Full site editing was not just an editor improvement. It was a theme architecture problem. The theme still needed to define what good looked like, even if more of the structure could now be adjusted inside WordPress.
Thinking About Templates Differently
The biggest shift was templates. Previously, I would think about templates as files first. A single post template, an archive template, a page template and a few custom templates would define how the site behaved. With block templates, the same ideas still exist, but the editing model changes because the structure can be represented through blocks rather than only through PHP.
That sounds like a small difference until you start thinking about maintenance. If a header is edited in the site editor, where does that decision now live? If a template part is changed by an editor, how do I know whether that change was intentional or just an experiment? If a layout starts drifting away from the design, how much of that should be controlled by the theme and how much should be left to the editor?
These are not reasons to avoid full site editing. They are the practical questions that appear once the feature moves from a demo into a working website. My thinking was that block themes would need stronger design rules, not fewer. The editor may provide the interface, but the theme still needs to provide the boundaries.
The Role Of Patterns And Reusable Sections
Patterns became one of the more interesting parts of this. Rather than giving someone an empty canvas, I could create sections that already carried the right spacing, hierarchy and content structure. That felt much closer to how I like client sites to work. The editor gets flexibility, but the flexibility starts from designed sections rather than from disconnected blocks.
For example, a services section might need an intro, a short piece of supporting text and several service cards. In a traditional theme, that might have been a template section or a custom field group. In a full site editing setup, a block pattern can represent the same thinking in a way the editor can insert and adjust. The difference is that the content team sees the pattern as something they can use, rather than as a hidden developer structure.
That has real value, but it also means the patterns need to be designed carefully. A messy pattern library will create the same problems as a messy theme options page. The useful work is deciding which sections people genuinely need and how much freedom each section should have.
Retrospective Thoughts
My view of full site editing in 2022 is still cautious, but much more constructive than it was when I first started looking at it. I do not think every project should immediately become a block theme, and I would still be careful about using it on a site where the editing experience needs to be tightly controlled. I do think it changes the conversation around WordPress themes in an important way.
The theme is no longer only a collection of templates and styles. It is becoming a system of blocks, patterns, template parts and design settings that need to work together over time. That requires more planning, not less. If full site editing is treated as a shortcut, it will create inconsistency. If it is treated as theme architecture, it can give editors more control without making the website harder to manage.