At the start of 2019, Gutenberg was no longer something I could treat as a future WordPress conversation.
WordPress 5.0 had already shipped at the end of the previous year, and that meant the block editor was no longer only something being tested in plugin form. It was now the editing experience many clients would meet when they logged into their websites. That changed the conversation because the editor was no longer just the place where content was entered. It was starting to shape how pages were structured, how content was reused and how much control a client could reasonably have without the website turning into a mess.
Before that point, a lot of WordPress builds were planned around a familiar pattern. There were page templates, custom fields, a few flexible content areas and a classic editor box that handled the main body copy. That approach still worked, however Gutenberg made me think more carefully about the relationship between design, content and editing. The website was not just something I built and handed over. It was something someone would keep assembling and adjusting over time.
Starting With The Editor People Actually Use
The first adjustment was to stop treating the admin experience as separate from the website itself. A client might spend more time inside the editor than on the front end, especially once the site is live and they are writing posts, changing service pages or adding new landing pages. If the editing experience feels confusing, the website gradually suffers because content starts being entered in whatever way feels easiest at the time.
That meant the block editor needed to be considered during planning, not after development. I wanted to know which parts of the site should be controlled by blocks, which parts should remain locked inside templates and which decisions should not be left open at all. Too much freedom can be just as damaging as too little. A client should be able to manage content, but they should not need to become a designer every time they add a section.
This was where Gutenberg became interesting. It gave editors more flexibility, but it also forced developers to think harder about guardrails. A good editing system should make the correct content decisions feel obvious. It should not require someone to remember a handover document every time they create a page.
Designing Blocks Without Rebuilding A Page Builder
One of the early risks with Gutenberg was treating every block like a miniature page builder component. That route can get messy quickly. If every section has too many controls, too many layout options and too many style choices, the editor becomes slower to use and the website becomes harder to keep consistent.
My preference was to think about blocks as content patterns rather than design toys. A testimonial block should help someone add a testimonial in a structured way. A call-to-action block should give them the fields needed to create a useful section. A gallery block should present images in a way that matches the site rather than asking the editor to rebuild the design from scratch.
That distinction mattered because most clients do not want endless design control. They want to publish something confidently without breaking the website. The development work therefore had to sit somewhere between freedom and restraint. Gutenberg made that balance more visible.
The Theme Had To Support The Editor
The next part was theme support. A block can look one way in the editor and another way on the front end if the theme does not support it properly. That creates a strange experience for editors because the place where they write content does not match the place where visitors see it.
I started paying more attention to editor styles, spacing, alignment support and the way default blocks behaved inside the theme. It was no longer enough for the front end to look right. The editing environment had to reflect enough of the front end that people could understand what they were creating.
add_theme_support('align-wide');
add_theme_support('editor-styles');
add_editor_style('editor-style.css');Those small decisions made the editor feel more connected to the website. They also reduced the gap between development and content management. When the theme supports the editor properly, the client is less likely to fight the system after handover.
How It Changed Client Handover
Gutenberg also changed how I thought about handover. In the classic editor, training often focused on where to enter text, how to add images and which custom fields controlled which parts of a page. With blocks, the conversation became more about composing content from available patterns.
That is a different type of training. It is not enough to show someone which button adds a block. They need to understand why one block exists, where it should be used and what happens if they try to use it outside its intended context. The handover becomes less about clicking through the interface and more about explaining the content model behind the website.
I think that is a good thing when it is done properly. It encourages clearer thinking around content. It also makes poor structure harder to hide, because if the blocks do not make sense to the editor, the build probably has not been thought through properly.
Retrospective Thoughts
Looking back at Gutenberg in 2019, I think the most useful shift was not the editor itself. It was the way it forced WordPress developers to think about content after launch. A website does not stay still. People add pages, edit sections, reuse layouts and make small decisions every week that gradually affect the quality of the site.
Gutenberg made those decisions more visible. Used badly, it could give clients too much control and create inconsistent pages. Used carefully, it could give them a better way to manage structured content without depending on a developer for every small change. That was the part I found most interesting. The editor was not only a technical change. It was a change in how WordPress websites were going to be lived with after they were built.