Your marketing team ships pages without engineering. How that works in WordPress
A campaign landing page is due Thursday. The design is signed off, the copy is written, and the change still goes into the engineering queue. We see this pattern in most WordPress platforms built before 2022, regardless of how strong the teams are on either side.
WordPress solved this at the platform level. It was called Full Site Editing. In current terminology it is the Site Editor and block themes. The mechanics are unchanged: the content team gets real control over page layout, and engineering stops being the bottleneck on every change.
This article explains how it works, and the one condition that decides whether it works at all. At the end we share the recording of a webinar we ran with the design studio Kreatik.
Three mechanisms behind Full Site Editing
This is not a single feature. It is three mechanisms, each solving a different part of the problem. Worth separating them.
The visual editor. It covers templates and site-wide elements, not just posts and pages. Header, footer, archive layout, 404 page – all edited in the same interface as content.
The styles interface. One place that defines the color palette, typefaces, font sizes and spacing. The team picks from a defined set instead of choosing colors by hand. This is a consistency mechanism, not cosmetics.
A theme built from blocks. Fully editable, with no rigid PHP templates to return to every time the structure changes.
Where the bottleneck comes from
In the classic setup, content goes into form fields and the result is only visible on the front end. Dynamic elements are inserted with shortcodes that have to be learned and are easy to break. Changing the structure of a section means touching code.
The outcome is predictable. A non-technical editor works blind, and after two mistakes stops experimenting. Every small change goes back to engineering, because that is faster and safer. The queue grows and campaign time-to-market is measured in weeks.
This is not a team problem. It is a consequence of an architecture that never assumed the content team would work on its own.
The block model: blocks and patterns
In the block model every element on the page is a block: paragraph, image, table, button, slider, FAQ block, post list, calendar. Pages are assembled from them.
Above blocks sit patterns – predefined groups of blocks, typically a complete page section. A hero with heading, text, button and image is one pattern. A three-tile section is another. Whoever builds the landing page inserts a ready pattern and replaces the content inside it. They are not designing the section from scratch, and there is no way to break its layout.
Core WordPress ships a reasonable block library. The real value appears when custom blocks are added during implementation.
Custom blocks: an example from an affiliate platform
For a client in the affiliate segment we built a comparison block. An editor drops it into the content and fills in the fields: operator name, expert rating, score, conversion button. The block handles layout, responsiveness and visual consistency on its own.
Without that block, the same section is a developer task on every publication. With it, it is five minutes of editorial work. On a site publishing a dozen or more reviews a month, the difference in running cost is straightforward to calculate.
The scope of what can be closed inside a block is wide. Calculators, filtering layers, comparison tables, sections pulling data from an external system. On SCCG Management we built the native search and filtering layer on the WordPress Interactivity API, with no additional plugins.
The condition that decides the outcome: a design system
This is where most block implementations drift within six months. The Site Editor gives editorial teams a lot of freedom. Without a defined component set, that freedom turns into fifteen variants of the same button.
A design system is a set of rules, patterns and design guidelines that govern how a digital product is built and extended. In Brad Frost’s Atomic Design methodology it has five levels: atoms, molecules, organisms, templates, pages. An atom is an input field or a button. A molecule is a search box made of a label, an input and a button. Above that sit full sections and pages.
During the webinar, Aleksandra Strelczuk of Kreatik cited three market figures. Adobe research puts the reduction in project delivery time at 52% when working with a design system. Airbnb reported a 30% reduction in designer time after rolling out its Design Language System. Shopify reports 95% less time needed to build user interfaces since introducing Polaris.
These numbers come from those companies’ own communication and describe large organizations with multiple products. The direction matches what we see on our own projects: you pay for consistency once, at the design stage, or repeatedly, on every new page.
A design system pays off most when an organization is scaling an existing product, running several sites with different interfaces, or seeing style and color drift between views. It is also the natural moment when redesigning a current platform.
What the project actually looks like
The order of work is the opposite of what most people expect. We do not start with pages.
Once the design is delivered, we break it down into components. Developers define individual sections as patterns, then assemble pages from them. This means the design has to answer questions a classic mockup never asks: how will the team work with this platform, how often will it change, which components are needed to extend it.
That is why on migrations from page builders to Gutenberg we start with a component inventory rather than rewriting templates. Skip that step and you get a block theme that is technically modern and still needs a developer for every change.
At AcadeMedia, the internal team took over full platform maintenance within 8 months of our engagement. That outcome is a function of the component library and documentation, not of how much code was written.
What changes at the organizational level
- Less dependency on front-end engineering for content and layout changes
- Changes visible immediately in the editor, with no switching between admin and front end
- More editorial control over page layout within defined standards
- Easier brand consistency when several people work on the same platform
- Faster onboarding, because it is visible what each block does
- A foundation built on core blocks rather than an extra plugin layer, which leaves more room for Core Web Vitals work
The last point matters on platforms where performance maps to revenue. A page builder layer always costs something in the numbers. The block model does not carry that overhead.
Webinar recording
Below is the full recording of “WordPress Full Site Editing and Design Systems”, a webinar we ran with the design studio Kreatik in September 2023. The recording is in Polish.
Agenda:
- the block editor concept and how it compares to the classic approach (Pawel Zmyslowski, WLC)
- design systems: what they are, who they are for, when to implement one, Figma walkthrough (Aleksandra Strelczuk, Kreatik)
- live demo on a real project: building a page from scratch, working with patterns, Query Loop, editing site-wide elements (Bartosz Ornaf, WLC)
What has changed since the recording
The recording shows the 2023 interface. The principles hold, the tooling has moved. The differences that matter if you are watching this today:
Terminology. “Full Site Editing” has left the official WordPress vocabulary. It is now the Site Editor and block themes. The FSE acronym is still in common industry use.
Gutenberg Phase 2 is closed. It concluded with WordPress 6.3. The Site Editor is no longer an experimental surface but the default way of working with block themes.
Governance mechanisms arrived. The Block Locking API locks selected blocks and settings, so editorial teams work within defined boundaries. Pattern Overrides allow content to be replaced inside a pattern without touching its structure. The Block Bindings API connects custom fields to core blocks without additional code. This addresses the main objection from 2023, that broad editing freedom is a risk on an enterprise platform.
Phase 3 is underway. It covers collaboration and editorial workflows. Releases 7.0 and 7.1 brought asynchronous notes in the editor, per-breakpoint styling controls and assisted migration for classic themes. For organizations planning a migration this has a practical consequence: work that recently required custom development now sits in core.
If you are making a platform decision today, the reference point is the current state, not the one in the recording. We are happy to walk through it on your platform. Talk to a WordPress expert
