The WordPress Gutenberg Controversy 2018-2022: What We Learned

The WordPress 5.0 release on December 6, 2018 was the most contested release in the project’s history. It shipped Gutenberg, the new block-based editor, as the default for every post, page and custom post type. It also shipped, on the same day, a fully supported escape hatch called the Classic Editor plugin, designed by the WordPress contributors team to let users opt out indefinitely.

The escape hatch told you everything about the political situation. Other open-source projects (Drupal, Joomla, Django) had shipped breaking-change editorial overhauls without an opt-out. WordPress, with its 30 percent share of the public web at the time, could not. Matt Mullenweg pushed the release through on the original schedule anyway, the Classic Editor plugin crossed one million active installs within weeks, and the community fractured into three camps that took the next four years to reconverge.

This piece walks through the four years of Gutenberg) controversy chronologically, what each phase actually shipped, and the 2026 retrospective verdict on a fight that consumed an unusual amount of community oxygen.

The 2017-2018 announcement + the WordPress 5.0 deadline

Gutenberg was announced at WordCamp Europe 2017 in Paris by Matt Mullenweg, and the early framing was ambitious. The pitch was a three-phase roadmap: Phase 1 replace the post editor with blocks (the “Gutenberg” phase, 2018), Phase 2 extend blocks to widgets and menus (2019), Phase 3 introduce Full Site Editing where the entire theme is composed of blocks (2020).

The first beta of Gutenberg shipped as a feature plugin in June 2017. It was rough. The drag-and-drop interactions were unreliable, the keyboard navigation was incomplete, the accessibility audit had not been done, and the existing TinyMCE editor (which had shipped with WordPress since version 2.0 in 2005) had been refined for thirteen years against real-world editorial workflows.

The 5.0 release deadline was the political flashpoint. The original target was August 2018. It slipped to November, then to December 6 after a difficult release-candidate phase. The deadline pressure produced a release that critics described as premature and supporters described as inevitable. The WordPress core team’s position was that shipping was the only way to get real-world feedback at scale; the opposition’s position was that real-world feedback was being collected, in the issue tracker, and the answers were being overridden.

The Classic Editor plugin was the compromise. It was developed in parallel by the core contributors team, committed to a four-year minimum support window (later extended through 2024, and then again through 2026 and beyond), and released the same day as 5.0. The plugin received about 700,000 active installs in the first two weeks, and crossed one million inside two months.

Classic Editor plugin reaches 8M+ active installs (the resistance)

The Classic Editor install count is the cleanest single metric of the Gutenberg controversy. The plugin sat at 1 million in early 2019, 2 million by mid-2019, 5 million by 2021, and crossed 8 million active installs by 2024. By 2026 it remains one of the top-installed plugins on the wordpress.org plugin directory, often in the top ten.

What the install count actually measures is more nuanced than “users who hate Gutenberg”. The plugin’s audience splits roughly into four groups:

• Editorial workflows that depend on specific TinyMCE plugins (advanced custom fields integrations, custom shortcode UIs, structured author workflows). Migrating those required rebuilding tooling that had been refined for years.
• Accessibility-driven installs. Sites with WCAG compliance obligations chose Classic Editor because the block editor’s accessibility audit did not pass the same bar as TinyMCE, particularly for screen reader users navigating long posts.
• Hosting providers that pre-installed Classic Editor on managed WordPress accounts to reduce support tickets. WP Engine, Bluehost, and several others ran this pattern at various points.
• Genuine opposition. A long tail of users who tried the block editor and chose not to migrate.

The persistence of these install numbers seven years after the WordPress 5.0 launch is the most concrete evidence that the controversy was not purely a generational learning-curve issue. The Classic Editor plugin has crossed every major WordPress release since 5.0 (6.0, 6.1, 6.2 through 6.7, and the current 6.8 in 2026) without losing meaningful share.

The learning curve and the meta-block accessibility problems

The 2018-2019 accessibility complaints were the sharpest. Joe Dolson, the WordPress accessibility lead, resigned publicly in October 2018 along with the rest of the accessibility team, citing repeated unresolved issues with screen reader support in Gutenberg. The WPCampus higher-education community, which had commissioned an independent accessibility audit of Gutenberg in 2018, published findings recommending that institutions with accessibility obligations should not deploy the block editor in its current state.

The audit, conducted by Tenon.io, identified more than 90 individual accessibility issues across the editor surface. A subset were addressed before WordPress 5.0 launched. Most were not. The WPCampus statement at the time recommended that institutions either delay upgrading to 5.0 or use the Classic Editor plugin, which most of them did.

The community management response was uneven. Matt Mullenweg’s State of the Word talks in 2018 and 2019 acknowledged the accessibility complaints but framed them as transitional problems to be solved on the existing roadmap. The accessibility contributors’ position was that the roadmap itself had been set without enough input from accessibility specialists, and that the gap was structural rather than transitional. Both positions had merit. Neither side updated.

The learning-curve question was less politically charged but more widespread. Users who had been writing posts in TinyMCE for years had built muscle memory that did not transfer. The “shift-enter for line break”, the “select text and click bold”, the keyboard shortcuts for headings, the paste-from-Word handling, all worked differently in Gutenberg. The block editor’s learning curve was real, and the WordPress documentation team did serious work between 2019 and 2022 to bridge it, but the cost of that bridge was distributed across millions of users and was rarely captured in any official metric.

The WordPress Core team handle on these issues over the four-year arc was incremental rather than coordinated. Individual problems got fixed in individual releases. The cumulative experience improved. But the controversy was not really about any single bug; it was about how a roadmap had been imposed faster than the community could absorb, and the catch-up never quite caught up.

Full Site Editing arrival 2022 (WordPress 5.9) + Gutenberg as the canvas

The pivotal release was WordPress 5.9, codenamed Josephine, which shipped on January 25, 2022. The defining feature was Full Site Editing (FSE), which had been the Phase 3 promise of the original 2017 announcement. With 5.9, blocks were no longer just for post content; they were the composition primitive for the entire theme. Headers, footers, sidebars, archive layouts, and home pages were all composed of blocks. The new default theme, Twenty Twenty-Two, was the first block theme to ship with core.

The technical architecture by 2022 had matured significantly. Block patterns (introduced in 5.5, August 2020) let designers ship reusable layouts. The block directory (introduced in 5.5) let third parties distribute custom blocks. The theme.json file format (introduced in 5.8, July 2021) let theme authors define a consistent set of design tokens (colours, font sizes, spacing, layout widths) that all blocks would inherit. The Global Styles UI in 5.9 let users edit those tokens visually.

What 5.9 finally delivered was the original 2017 thesis. A WordPress site was now, end to end, a block-edited document. The same UI that edited a post could edit the header. The same blocks that composed a paragraph could compose an archive listing. The promise had been made four years too early, and the community fracture was the cost of that four-year gap. But the promise had been delivered.

The reception in 2022 was mixed but warmer than 2018-2020. The theme developer community, which had been the most resistant to FSE in 2020-2021, started shipping block themes through 2022 and 2023. The pace was slow but real. By 2024, every major freemium theme vendor (Astra, GeneratePress, Kadence, Blocksy) had a block-theme product line. The classic-theme ecosystem did not disappear, but the centre of gravity moved.

Plugin and theme ecosystem adaptation 2022-2024

The two-year window from 5.9 (January 2022) through WordPress 6.4 (November 2023) was when the broader ecosystem caught up. The pattern broke down by ecosystem segment:

• Page builder plugins (Elementor, Beaver Builder, Divi, Bricks) initially competed with Gutenberg by positioning themselves as the “real” design tool while Gutenberg was the “developer” tool. By 2023, all four had shipped meaningful Gutenberg interop, either by adding block-editor compatible widgets or by adopting the block-editor as the primary canvas.
• Form plugins (Gravity Forms, WPForms, Fluent Forms) shipped block-editor integration earlier (2020-2021) because the form embedding pattern was straightforward.
• WooCommerce blocks shipped progressively from 2019 onwards, with the Cart and Checkout blocks reaching production-ready status in 2022. The Shop and Product Catalog blocks followed in 2023.
• Theme vendors were the slowest to adapt. Block themes require a different architectural approach (theme.json-driven, block-template-based) and rebuilding an existing classic theme as a block theme is roughly the cost of writing it from scratch. The major commercial themes ran both classic and block lines in parallel through 2024.
• Custom field plugins (Advanced Custom Fields, Meta Box, Pods) shipped Gutenberg integration through 2019-2021. ACF’s “Block Editor” integration in particular became a workhorse for custom block development by agencies.

The ecosystem adaptation was real but slower than the original 2017 roadmap implied. Four years to converge on FSE, plus another two for the ecosystem, plus another two to push penetration into the production install base, means the full Gutenberg transition is on a roughly ten-year timeline rather than the three-year one originally promised.

The 2026 verdict: block editor won, classic still served when needed

Eight years after WordPress 5.0 launched, the verdict is reasonably clear and reasonably nuanced.

The block editor won. The default editor on a new WordPress install in 2026 is Gutenberg. Block themes are the recommended default for new sites. The Full Site Editing experience in 6.8 (the current release) is mature enough that small business sites and personal blogs can be built end-to-end without a third-party page builder. The community has converged on blocks as the composition primitive, and the long-running theme-versus-page-builder versus-Gutenberg three-way war has effectively ended with Gutenberg as the centre of gravity.

The Classic Editor still serves a real population. Eight-million-plus active installs in 2026 is not a residual rounding error; it is a persistent population of editorial workflows that the block editor either does not serve well or is too disruptive to migrate. The official commitment to maintain Classic Editor has been extended again, and the WordPress contributors team appears to have accepted that the plugin is a permanent fixture rather than a transitional support tool.

The community cost was real and probably under-counted in the official retrospectives. The accessibility team’s 2018 resignation was followed by a multi-year contributor drought in that area. The acrimony of the 2018-2020 period drove some long-tenured contributors out of the project entirely. The Classic Editor population represents users who lost trust in the project’s roadmap process, and that trust did not fully return even after FSE shipped.

The lesson for open-source governance, which the WordPress retrospective from cafelog to block editor on this archive treats more broadly, is that a project’s distribution dominance does not eliminate the obligation to manage breaking changes carefully. WordPress at 30 percent of the web in 2018 had more leverage than any other open-source project to push a controversial editorial change, and it used that leverage. The 2026 verdict is that the change was probably the right one, but the way it was pushed cost the project years of contributor goodwill and a permanent fork in the user base.

For the broader WordPress topic page on this archive, the Gutenberg arc is the single most consequential event in WordPress’s last decade, and the only one that comes close to mattering as much as the original 2003 b2/cafelog fork that started the project.

FAQ

What was the Classic Editor plugin?

The Classic Editor plugin restored the pre-Gutenberg TinyMCE editor inside WordPress 5.0 and later. It was officially maintained by the WordPress contributors team (originally led by Andrew Ozz), distributed through the wordpress.org plugin directory, and committed to long-term support. It crossed 1 million active installs within weeks of WordPress 5.0 launching in December 2018, crossed 5 million in 2021, and crossed 8 million in 2024. By 2026 it is still maintained and the support commitment has been extended multiple times. It is the most-installed plugin in WordPress history that exists specifically to undo a default behaviour of WordPress core.

Why was Gutenberg controversial?

Three reasons. Accessibility: the initial release had documented screen-reader and keyboard-navigation problems, the WPCampus higher-education community commissioned an independent audit in 2018 that found 90+ issues, and the entire WordPress accessibility team led by Joe Dolson resigned in October 2018 in protest at the unresolved state of those issues. Learning curve: existing users with decade-old workflows in TinyMCE had to relearn their editing pattern, and the migration tax was distributed across tens of millions of sites. Roadmap: the original 2017 Gutenberg promise was a unified block model across content, widgets, and full site editing, but Full Site Editing did not ship until WordPress 5.9 in January 2022, four years late, leaving theme developers in roadmap limbo for the entire interim.

When did Gutenberg become acceptable?

The consensus shifted between WordPress 5.9 (January 2022) and 6.0 (May 2022). 5.9 finally shipped Full Site Editing, which was the original 2018 promise and the missing piece that made Gutenberg a complete answer rather than a partial one. 6.0 polished the block editor enough that the daily editing experience matched or exceeded TinyMCE for most workflows. By 2023 the active opposition had quieted, the theme and plugin ecosystem had largely converged on blocks, and new sites were defaulting to block themes. The Classic Editor user base remained large, but new controversy had died down.

Is Classic Editor still maintained 2026?

Yes. The Classic Editor plugin is still officially maintained by the WordPress contributors team in 2026, with the long-term support commitment extended multiple times (originally through 2022, then 2024, then 2026, with further extensions expected). It remains one of the most-installed plugins on the wordpress.org directory and is recommended for sites with editorial workflows that depend on TinyMCE-specific behaviour, accessibility constraints that the block editor still does not meet, or institutional change-management policies that have not approved the block editor for production use. The plugin is treated by the WordPress project as a permanent fixture rather than a transitional artefact.