WordPress shipped the Gutenberg block editor in core this year, replacing the classic TinyMCE-based editor that every WordPress site we have built has used since we started doing this work. It is the biggest change to the WordPress editing experience in years, and it required real preparation on our end for existing client sites rather than something we could treat as a routine minor-version update.
What actually changes under the hood
The classic editor stored post content as a single blob of HTML, edited through a rich-text interface layered on top. Gutenberg instead stores content as a series of discrete blocks — a paragraph block, an image block, a custom call-to-action block — each represented internally as HTML wrapped in specially formatted comments that WordPress uses to know where one block ends and the next begins. This is a genuinely different model, and it has real consequences for any theme or plugin that assumed content was just an opaque string of HTML to be rendered as-is.
Auditing our existing themes
Our custom theme templates that relied on specific classic-editor output formatting needed review, since Gutenberg wraps content in block-level markup that does not always match what a classic-editor theme expects. A theme's CSS written years ago to target `.entry-content p` styling assumed a particular DOM shape that block-level wrapper markup can subtly disrupt, and we found several client themes with visual regressions — inconsistent spacing, misaligned images — that only appeared once real content was edited in the new block editor rather than migrated over unchanged from the old one.
Building custom blocks for complex client needs
For clients with heavily customized content layouts, we built custom blocks specific to their needs — a call-to-action block, a testimonial block — rather than leaving them to recreate complex layouts with shortcodes inside the new editor. Building a custom block for the first time involved a real learning curve of its own: Gutenberg blocks are built in JavaScript using React, which meant our WordPress-focused developers needed a crash course in a frontend framework most of them had only touched at the edges before, and our first custom block took considerably longer to build than we initially estimated because of that unfamiliarity.
What we tell editorial teams before the switch
- A short recorded walkthrough of the new editor's core interactions, since even an editor who has used WordPress for years will find the block-based interface genuinely different from what they are used to
- A list of exactly which custom blocks are available for their site, since the block inserter's default library is large and can be overwhelming without guidance on which blocks are actually meant for their specific content needs
- A clear point of contact for the first few weeks after the switch, since real questions tend to surface only once an editor is working with actual content rather than a demo
Rolling out gradually rather than all at once
We rolled the switch out gradually, site by site, rather than all at once, giving each client's editorial team a walkthrough before their site updated. This was slower than flipping the switch everywhere simultaneously, but it meant each rollout benefited from lessons learned on the previous one, and it meant we never had more than one or two clients simultaneously adjusting to a major workflow change, which kept our own support load manageable during the transition.
Mixed feedback, and what we made of it
Feedback so far is mixed — some editors love the more visual, block-based approach, others miss the simplicity of the old editor — but it is clearly where WordPress is heading, and getting ahead of it site by site beat a scramble later. The editors who struggled most tended to be the ones doing the simplest, most repetitive content updates, where the old editor's straightforward text box was genuinely faster for their specific workflow than composing several blocks would be. For those clients, we kept the classic editor plugin installed as a bridge for now, treating it as a deliberate transition aid rather than a permanent fallback, since Gutenberg's continued development means the classic editor plugin will not be supported indefinitely.
What this means going forward
Every new client project now starts directly in Gutenberg rather than the classic editor, and any custom theme work we do going forward is built with block-based content structure in mind from day one, rather than as an afterthought layered onto assumptions the classic editor era baked in. It is a meaningfully different way to think about WordPress theming than we were used to, and we expect the gap between block-aware and block-unaware WordPress development to only widen from here.
Migrating existing content, not just future content
A question that came up repeatedly during rollout planning: what happens to years of content already written in the classic editor once a site switches over. Gutenberg handles this more gracefully than we initially expected — existing classic-editor content continues to render correctly inside a single "classic" block, without requiring any migration, and an editor can choose to convert it into native blocks later if they want finer editing control, but is never forced to. We made sure every client understood this up front, since a couple of editorial teams had assumed, incorrectly, that switching to Gutenberg meant a disruptive one-time conversion of their entire content archive.
Plugin compatibility was its own project
Several client sites depend on third-party plugins that had not yet updated their own admin interfaces to work cleanly inside the new block editor, and a couple produced visibly broken meta boxes or SEO fields when Gutenberg was enabled without any further work. We ended up maintaining a small internal compatibility list, tracking which of our commonly used plugins worked cleanly, which needed the classic editor plugin as a bridge, and which needed an updated version before a given client's site could safely switch over, updating it as plugin authors caught up with Gutenberg's release over the following months.
Performance considerations in the editor itself
The block editor's React-based interface is noticeably heavier in the browser than the old TinyMCE-based editor was, and on a couple of client sites with very long-form content — a documentation-style page with dozens of blocks — editors reported the editing experience itself feeling sluggish in a way the old editor never had. We traced part of this to a couple of third-party blocks each running their own independent re-render logic inefficiently, and worked with the affected plugin authors to report the specific performance issue, which is a new kind of troubleshooting we had not previously needed to do as WordPress developers before blocks became JavaScript applications in their own right running inside the editor.
What we now build differently in new themes from day one
Every new WordPress theme project now starts with block-editor compatibility as an explicit design constraint rather than something checked afterward, including full editor-style CSS so a block looks the same while editing as it will on the published page, which was a rough edge on our earliest Gutenberg-era themes where what an editor saw while composing did not always match the final rendered result closely enough to be trustworthy. We have since started keeping a small internal library of custom blocks shared across client projects with similar needs, rather than rebuilding a testimonial block or a call-to-action block from scratch for every new client, which has cut the time a typical custom block takes to ship by a meaningful margin.
Working with clients who wanted to skip Gutenberg entirely
A couple of clients, having heard mixed things from other agencies or from their own editorial staff's early frustration, asked whether they could simply stay on the classic editor indefinitely rather than adopting Gutenberg at all. We were honest that this was possible in the near term via the classic editor plugin, but explained clearly that WordPress core's own long-term direction meant an indefinite delay was borrowing against future pain rather than avoiding it, since plugin and theme compatibility with the classic editor bridge will only get thinner over time as more of the ecosystem builds specifically for blocks. Every client we had this conversation with ultimately chose to move forward with Gutenberg on a timeline of their own choosing rather than delaying indefinitely, once the tradeoff was laid out plainly.