When the block editor shipped in WordPress 5.0 in December 2018, it arrived under a code name everyone still uses: Gutenberg. The naming was deliberate. This was supposed to be a printing-press moment for WordPress, a once-in-a-generation reset of how content gets created. Seven-plus years and dozens of releases later, the loud arguments have mostly died down, the Classic Editor plugin is still installed on millions of sites, and the editor itself has quietly become something the 2018 version barely hinted at. This is an honest accounting of where Gutenberg actually landed, what improved, what stalled, and how to make decisions about it in 2026.

The thing most retrospectives get wrong

People still talk about "Gutenberg" as if it were a single 2018 release you either accepted or rejected. That framing is years out of date. The editor that shipped in 5.0 was rough: janky text selection, no list view, weak keyboard handling, and a reusable-blocks feature that quietly broke content if you weren't careful. The editor in WordPress 6.7 and 6.8 is a different tool. The fair question isn't "was launching Gutenberg a mistake" — that argument is settled by adoption — but "has the platform delivered on the *block model* as a foundation, and where is the foundation still cracked?"

Two separate things hide under the Gutenberg umbrella, and conflating them is the source of most confusion:

The post/page block editor — the writing surface that replaced TinyMCE. This is mature. It works.
Full Site Editing (FSE) — the much more ambitious project to make headers, footers, archives, and entire templates editable as blocks, governed by theme.json and block themes. This is the part that is still genuinely contentious in 2026.

What the block editor actually got right

Strip away the politics and a few wins are undeniable.

theme.json changed how design systems work

The single most underrated outcome of this whole project isn't a block — it's theme.json. It gives a theme one declarative place to define color palettes, font sizes, spacing scales, and layout widths, and it propagates those tokens into the editor UI so writers pick from a constrained, on-brand set instead of free-typing hex codes. This is the design-token pattern that front-end developers spent the 2010s building by hand, now baked into the platform. For agencies handing a site to a non-technical client, it is a real guardrail against brand drift.

Patterns beat shortcodes and page-builder lock-in

Block patterns — and the pattern directory — let you drop in pre-composed, on-brand sections (a pricing table, a testimonial row, a CTA band) that become ordinary editable blocks. Unlike a page builder's proprietary modules, the output is core block markup. If you later switch themes or disable a plugin, your content is still standard HTML comments and markup, not a tangle of [vc_row] shortcodes that render as plain text once the builder is gone. Synced patterns (the rebranded "reusable blocks") give you a single source of truth for something like a promo banner that needs to update everywhere at once.

The block ecosystem matured past the core set

Core blocks are deliberately minimal, but the third-party libraries filled the gap well. GenerateBlocks (especially the v2 rewrite) is the lightweight-output favorite for developers who care about page weight. Kadence Blocks and Spectra serve the design-heavy, marketing-page crowd. Stackable and GreenShift push interactions and animation. Critically, these render closer to clean semantic HTML than the old Visual Composer / WPBakery generation ever did, so they don't carry the same Core Web Vitals penalty by default.

Where it still struggles

Structured content is the persistent sore spot

The block editor optimizes for free-form, mixed-media composition. That is exactly the wrong shape for highly structured content — real-estate listings, recipe databases, a directory of staff bios, technical documentation where every entry has the same ten fields. For that work you want enforced field consistency, not a blank canvas where an editor can delete the "price" block by accident. Advanced Custom Fields adapted with ACF Blocks, and Meta Box and Pods both interoperate with the editor now, but the cleanest answer for heavily structured post types is often still to turn the block editor off for those specific types. WordPress supports this per-post-type: register the post type with 'show_in_rest' => false or filter use_block_editor_for_post_type, and that one CPT falls back to the classic meta-box screen while the rest of the site stays on blocks. That selective approach has aged far better than the all-or-nothing Disable Gutenberg posture.

Programmatic content operations got harder

Block content lives in the post body as HTML wrapped in  comment delimiters. That's elegant for portability but awkward for bulk programmatic edits. A WP-CLI search-replace or a custom migration script that reliably rewrote classic content can mangle block markup if it touches the delimiters or the JSON attributes inside them. The right tool is the block parser (parse_blocks() / serialize_blocks() in PHP, or @wordpress/block-serialization-default-parser in JS) rather than naive string replacement — but that's a real workflow tax for sites that do mass content manipulation as a routine.

Full Site Editing remains a two-track reality

This is the honest middle. FSE works, and for a brochure site, a small business, or a blog on a block theme like Twenty Twenty-Five or Ollie, editing the header and footer visually is genuinely nice. But for complex, conversion-critical sites, a large share of developers still ship classic PHP templates or hybrid themes and treat FSE as the lighter-duty option. The Interactivity API (introduced in WordPress 6.5) is closing the gap for dynamic front-end behavior, but the tooling for version-controlling template changes, handling complex conditional layouts, and onboarding a team raised on PHP templates is still rougher than the post editor's equivalent. Saying "FSE is the future" is fair; saying "FSE is production-ready for every site today" is not.

How to decide in 2026

The practical guidance has become fairly clear-cut.

New site, content-driven or marketing-focused? Build on the block editor, and seriously consider a block theme. The ecosystem momentum, the theme.json guardrails, and the steady pace of editor improvements all point the same direction. Fighting the platform's direction just accrues maintenance debt.
New site, heavily structured data? Use the block editor for your editorial content and disable it per-post-type for your structured CPTs, pairing those with ACF, Meta Box, or Pods. Don't force listings into a canvas built for essays.
Established classic-editor site with real investment? Don't migrate on vibes. The Classic Editor plugin is officially supported through at least the end of 2026 and realistically beyond. Tie any blocks migration to a concrete trigger — a redesign, a host migration, a content reorganization — so the effort buys something beyond "being current."

The five-years-later verdict

The block model won the argument it set out to win: blocks, not shortcodes or theme-option panels, are how WordPress content gets built now, and the data stays as portable standard markup. The post editor is good and getting better. theme.json quietly became one of the best things to happen to WordPress theming in a decade. The unfinished business is real too — structured content still wants a different tool, bulk operations are clumsier, and Full Site Editing is powerful but not yet the universal default its early roadmap promised. The mature position isn't "Gutenberg good" or "Gutenberg bad." It's knowing exactly which of the two Gutenbergs you're talking about, and choosing the editor surface that fits the content in front of you.

WordPress Block Editor (Gutenberg): Five Years Later