Gutenberg Isn't the Problem — Your Onboarding Process Is

The Block Editor Has a People Problem, Not a Technology Problem

Let's be honest: Gutenberg has been around long enough that calling it "new" is a stretch. It shipped with WordPress 5.0 back in late 2018, which means it's older than a lot of the projects your team is probably building on top of it right now. And yet, if you've ever handed a freshly built Gutenberg-powered site to a client or a junior developer, you've probably heard some version of the same complaint: "Can we just use the old editor?"

The frustration is real. But after digging into what actually causes teams to resist the block editor, the answer almost never comes down to Gutenberg itself being fundamentally broken. More often, it's a workflow problem — and workflow problems are fixable.

What's Actually Causing the Friction

Before you can solve the adoption issue, you need to understand where the resistance is coming from. There are a few common culprits.

The mental model shift is jarring. The classic editor was basically a fancy text box. You typed, you formatted, you published. Gutenberg asks users to think in blocks — discrete, stackable units of content. That's not a worse way to work, but it's a genuinely different way to work, and most teams don't give people enough time or guidance to make the mental transition.

The default block library is overwhelming. Out of the box, Gutenberg shows users a massive grid of available blocks. For content editors who just want to write a blog post, that interface feels like showing someone a cockpit when they asked for a steering wheel. The sheer number of options creates decision fatigue fast.

Custom block development has a steep entry point. For developers, the bigger frustration is often on the build side. Creating custom blocks requires React knowledge, which isn't a given for every WordPress dev shop. If your team is PHP-first, jumping into JSX and webpack configs can feel like learning a second job.

Client expectations are still shaped by page builders. A lot of US-based agency clients have used Elementor, Divi, or WPBakery at some point. They expect drag-and-drop fluidity with real-time visual feedback. Gutenberg's editing experience is closer to that than it used to be, but it's not identical — and the gap still trips people up.

Practical Fixes That Actually Work

Lock Down the Block Library

One of the most underused features in Gutenberg is the ability to restrict which blocks are available to editors. Using the allowed_block_types_all filter, you can whittle down the block menu to only what's relevant for a given project. For a news site, that might mean text, image, pullquote, and embed blocks. For an e-commerce build, you'd include WooCommerce-specific blocks and strip out the rest.

This single change reduces overwhelm dramatically. When editors open the inserter and see twelve options instead of a hundred and twenty, the experience feels manageable.

Build a Block Pattern Library Early

Block patterns — pre-configured combinations of blocks that users can insert with a single click — are one of Gutenberg's most underrated features. Instead of asking your content team to build layouts from scratch every time, you can pre-build the patterns they'll actually use: a standard hero section, a two-column feature callout, a team member card, whatever fits the project.

Registering custom patterns with register_block_pattern() takes maybe thirty minutes per pattern once you know what you're doing. That upfront investment saves hours of frustration for everyone who touches the site afterward.

Invest in a Proper Handoff Process

This sounds obvious, but most teams skip it: build a short, project-specific walkthrough video or written guide before handing a site to a client. Not a generic "here's what Gutenberg is" explainer — a this specific site, these specific blocks, this is how you add a new blog post walkthrough.

Tools like Loom make this dead simple. A five-minute screen recording that walks through the exact workflows a client will actually use is worth more than any amount of documentation.

When to Consider Alternatives

Here's the honest take: Gutenberg isn't the right tool for every project. If you're building a highly complex, design-heavy site for a client who needs granular layout control and isn't technical enough to work with Full Site Editing, a page builder might genuinely be the better call. There's no shame in reaching for Elementor or Bricks Builder when the project demands it.

Similarly, if your client is running a primarily text-heavy publication and has been using the classic editor for years without complaints, the ROI on migrating them to Gutenberg is low. The Classic Editor plugin is still officially supported, and sometimes the pragmatic move is to leave well enough alone.

Getting Your Development Team on Board

For developers specifically, the path to Gutenberg fluency runs through one of two routes: learning React properly, or using an abstraction layer like Advanced Custom Fields (ACF) blocks or the newer block development tools that let you build blocks with PHP and JSON rather than pure JavaScript.

ACF's block registration API, in particular, has been a game-changer for PHP-first shops. You define a block's fields in ACF, write a standard PHP template, and register it with a few lines of code. No webpack, no JSX, no build pipeline required. The result is a fully functional custom block that your team can actually maintain.

If you do want to go the native route, the @wordpress/create-block scaffolding tool has gotten genuinely good. It spins up a working block plugin with a proper build setup in under five minutes. Starting there rather than from scratch makes the learning curve a lot less steep.

The Bigger Picture

Gutenberg is the direction WordPress is heading — Full Site Editing, block themes, and the ongoing evolution of the editor all point that way. Fighting it wholesale is a losing battle for any team that plans to build on WordPress long-term.

But adopting it doesn't mean throwing your team into the deep end and hoping they figure it out. The developers and agencies that are thriving with Gutenberg right now aren't necessarily more talented than the ones who are struggling — they've just built better processes around the tool.

Fix the onboarding. Simplify the interface. Build the patterns. And be honest about the projects where an alternative editor is genuinely the better fit. That's how you stop fighting Gutenberg and start building smarter with it.