WordPress 6.8 shipped in April 2026. Phase 4 of the Gutenberg project, which was supposed to deliver collaboration and multilingual features, remains in progress three years after it was announced. Meanwhile, the block editor has become the undisputed center of the WordPress experience, and a new generation of AI-assisted builders has arrived to challenge the assumptions the project was built on. This is an honest look at where Project Gutenberg actually stands in 2026: the governance, the roadmap, the real shipping record, and what it means for developers and agencies building on WordPress today.

This piece is about the project and the governance narrative. If you want the block development angle and how AI has changed day-to-day block work, I covered that in Gutenberg blocks in 2026: the block editor in the AI era. These two threads are distinct. For agencies actively building on this stack, the differences matter significantly when making investment decisions about tooling and skill development.

I also want to frame this piece accurately: I have been building WordPress products since before the block editor existed. At Wbcom Designs, we went through the adaptation with our entire product line. The perspective here is from someone who had to make real bets on the Gutenberg roadmap and live with the outcomes. That context shapes what I think is worth examining.

Project Gutenberg: The Original Ambition

When Matt Mullenweg announced Project Gutenberg in 2017, the scope was clear and ambitious. Four phases covering the entire WordPress editing and customization experience:

  • Phase 1: Easier Editing. The block editor replacing the classic TinyMCE editor.
  • Phase 2: Customization. Full site editing, block themes, site-wide templates managed through the editor.
  • Phase 3: Collaboration. Real-time multi-person editing, revision history, comment threads inline in posts.
  • Phase 4: Multilingual. Native multilingual support built into WordPress core, ending the dependency on plugins like WPML and Polylang for basic language handling.

Phase 1 shipped in WordPress 5.0 in December 2018. The rollout was rocky. The dismissal of the feedback plugin showed in the adoption numbers: millions of sites reverted to Classic Editor immediately. What followed was a three-year process of rebuilding trust through iteration.

That rebuilding process is worth understanding because it shapes everything that followed. The Gutenberg team did not abandon the roadmap after Phase 1’s difficult reception. They absorbed the criticism, prioritized stability and feature parity with the classic editor, and kept shipping. The improvement curve from WordPress 5.0 to 5.9 was steep and genuine. By the time Full Site Editing arrived in 5.9, the block editor had become a product that professional developers and serious site builders could work with comfortably.

Phase 1 and 2: What Actually Shipped

By any honest accounting, Phases 1 and 2 of Gutenberg have shipped. Not perfectly, not without controversy, but functionally complete for the majority of use cases.

The block editor is now the default editing experience on every fresh WordPress installation. The ecosystem has adapted. Themes have moved to block themes or added block support. Page builder plugins have rebuilt their interfaces around block patterns. The WordPress.org theme directory has hundreds of Full Site Editing themes. Plugin developers write blocks as a first-class deliverable rather than an afterthought.

Phase 2, Full Site Editing, shipped progressively across WordPress 5.8 through 6.x. Site Editor, template editing, block themes, the Pattern Directory, style book, theme.json configuration, all of it is in production across millions of sites. The technology works. The onboarding curve for non-technical users remains steep, but that is a different problem from shipping the technology.

What is worth acknowledging: the team shipped a lot. From 2019 to 2024, WordPress releases came with substantial block editor improvements every cycle. The gap between Gutenberg plugin releases and core merge narrowed over time. The contribution team grew. The tooling around block development with @wordpress/scripts and the block editor packages matured into something genuinely usable.

Phase 3: Where Collaboration Actually Stands

Phase 3, real-time collaboration, was announced in 2021 as “the next major area of focus” after Full Site Editing reached a stable state. In 2026, it is still not in WordPress core.

The Gutenberg plugin has had experimental collaboration features under various flags since 2023. The architecture work has been significant: a collaborative editing protocol, conflict resolution logic, operational transformation implementation, presence awareness for multiple editors. This is hard engineering. Anyone who has built collaborative editing knows how difficult it is to get right at the data structure level before you even touch the UI.

The honest status as of mid-2026: the experimental collaboration features in the Gutenberg plugin work for basic cases. Multi-user cursors are visible. Real-time updates propagate. The edge cases, concurrent editing conflicts on complex blocks, network interruption recovery, merge behavior on structured content like tables and columns, are still being worked through.

There is no committed merge date for Phase 3 into WordPress core. The WordPress.org roadmap page acknowledges it is “in progress” without a release target. For agencies and developers planning around this feature, that means building on third-party collaboration tools or waiting indefinitely.

Why Collaboration Is Hard in the WordPress Context

The challenge with Gutenberg collaboration is not just the collaborative editing algorithm. It is the entire WordPress data model underneath it. WordPress stores post content as HTML, not as a structured document format. The Gutenberg blocks are encoded as HTML comments that WordPress renders. Implementing operational transformation or conflict-free replicated data types (CRDTs) on top of an HTML string is genuinely difficult in ways that tools like Notion or Google Docs, which control their own data models end-to-end, do not face.

Every solution requires tradeoffs between compatibility with existing content, performance at scale, and correctness under network partition conditions. The Gutenberg team is navigating this carefully, which explains the timeline. The risk of shipping a broken collaboration feature that corrupts post content would be catastrophic for a platform powering 40%+ of the web.

For practical planning purposes, agencies with clients who need real-time collaborative editing should not hold their breath for a core solution in 2026. The more productive approach is to build workflows around the current limitation. Assign clear post ownership, use WordPress revisions for version tracking, and document drafts in Google Docs before importing to WordPress. Imperfect but functional.

Phase 4: Multilingual Is the Long Game

Phase 4, native multilingual in WordPress core, is the most underspecified and least progressed of the four phases. The Gutenberg plugin repository has an ongoing “Internationalization” track, and there have been Make WordPress blog posts about the multilingual architecture. But as of mid-2026, no concrete implementation is in the Gutenberg plugin, let alone in core.

This is where the gap between ambition and execution is widest. The multilingual problem in WordPress is not just a technical problem. It is a market and ecosystem problem. WPML and Polylang have millions of active installations and significant revenue. Their approaches to multilingual content storage are incompatible with each other and with whatever core would implement. A core multilingual system would need to be backwards compatible with existing content, support the major plugin ecosystems, and not break the REST API, multisite, or any of the other data access patterns that the WordPress ecosystem has built on top of.

That is a genuinely hard governance problem, not just a technical one. The timeline for Phase 4 is effectively unknown. It will happen, but “in the next few years” is a truthful answer and an unsatisfying one.

For agencies with multilingual clients: WPML and Polylang are not going away in the near term. Choose a plugin and build your workflows around it. Core multilingual is a years-away promise. Your clients need functioning multilingual sites today, and the plugin ecosystem is mature enough to serve that need reliably.

The Governance Reality

One of the persistent tensions in the Gutenberg project has been the governance model. WordPress is open-source but Automattic has outsized influence over the project direction. The 5-for-the-Future program asks companies and individuals to contribute a portion of their time to WordPress core, but the coordination layer between contributors and the project roadmap is complex.

Governance FactorHow It Affects Gutenberg
Automattic engineering resourcesCore Gutenberg features often gated on Automattic priorities (WordPress.com products)
5-for-the-Future contributionsBroader contributor base but coordination overhead increases with scale
Plugin ecosystem pressureFeatures that compete with established plugins face slower adoption and push-back
Release cycles3 major WordPress releases per year; Gutenberg plugin releases on 2-week cycles
Community RFC processSignificant features require consensus across a diverse contributor community

The Mullenweg/WP Engine dispute in 2024 and 2025 added a new governance dimension. The visibility of the dispute around Advanced Custom Fields (ACF), the creation of Secure Custom Fields as an alternative, and the broader tension around commercial plugin makers and WordPress.org hosting requirements all played out against the backdrop of ongoing Gutenberg development. The contributor community absorbed these tensions, but they were distracting and energy-consuming at an organizational level.

For developers watching from the outside: the WordPress governance model is resilient but noisy. The project continues. The release cadence continues. Gutenberg development continues. But the organizational overhead of these disputes is real and affects where engineering attention goes.

What Actually Shipped in 2025 and Early 2026

Setting aside the phase framing, the actual shipping record of the Gutenberg project over the last 18 months is worth examining directly.

Block Bindings API

WordPress 6.5 shipped Block Bindings, a significant API that lets block attributes be connected to custom fields and external data sources. This is the foundation for making blocks data-aware without custom block code. For agencies building client sites with custom data, Block Bindings substantially reduces the need for custom block development for presentation layer work.

The practical impact is significant for data-driven sites. A client site that displays dynamic content from custom post meta no longer requires a custom block for each display variant. Block Bindings lets you connect an Image block’s source, a Paragraph block’s content, or a Heading block’s text to custom field values via a simple registration pattern. This is work that previously required either page builder shortcodes or custom block development.

Interactivity API

The Interactivity API, merged in WordPress 6.5, provides a standardized way to add client-side interactivity to blocks without relying on arbitrary React or jQuery. This matters for the broader ecosystem because it gives plugin developers a supported API for dynamic block behaviors that works with server-side rendering, caching, and the full WordPress request lifecycle.

I have used the Interactivity API in production on client projects and it is genuinely good. The directive-based approach is teachable to developers who are not React experts, and the performance characteristics are better than loading a full React bundle for minor UI interactions.

Style Book and Per-Block Styles

The Style Book in the Site Editor, shipped across WordPress 6.6 and 6.7, gives content editors a preview surface for how every block looks in the current theme. Combined with per-block style variations, this brings a level of design system control to WordPress that previously required custom tooling or page builder plugins.

WordPress 6.8 and Performance

WordPress 6.8, released in April 2026, continued the pattern of incremental improvements rather than headline features. Speculative loading for faster navigation, improved image performance defaults, and further refinements to the Site Editor were the notable changes. Solid release, no single feature that changes the conversation.

Gutenberg shipped the hard parts. The block editor is the WordPress editing experience now. Phase 3 and 4 will follow at their own pace, and the ecosystem should plan accordingly.
Gutenberg shipped the hard parts. The block editor is the WordPress editing experience now. Phase 3 and 4 will follow at their own pace, and the ecosystem should plan accordingly.

The AI Disruption: What It Means for the Gutenberg Roadmap

The most significant change in the WordPress editing landscape in 2025 and 2026 has not been a Gutenberg feature. It has been the arrival of AI-assisted site builders that can generate functional WordPress sites from natural language prompts.

Tools like ZipWP, 10Web, and custom implementations using the WordPress REST API with AI orchestration can produce fully built WordPress sites, complete with content, blocks, and styling, in minutes. The interaction model is fundamentally different from the block-by-block editing paradigm that Gutenberg was designed around.

This creates an interesting tension with the Gutenberg roadmap. Gutenberg was designed to give users direct, fine-grained control over page composition through a visual editing interface. AI site builders abstract away that composition layer entirely. The user says what they want; the system generates the blocks. Gutenberg becomes an output format rather than an input interface.

The project is aware of this. There are early experiments with AI-assisted block suggestions and content generation within the editor. But the architecture of Gutenberg as a primarily manual composition tool sits somewhat awkwardly with the direction the broader web is moving.

My read: Gutenberg will bifurcate into two usage modes over the next few years. AI-generated sites will use Gutenberg blocks as the output format without users touching the editor directly. Complex, custom editorial environments will use the editor directly with developers building specialized block configurations. The middle ground, non-technical users manually building complex pages block by block, will shrink.

What the Roadmap Gap Means for WordPress Agencies

For agencies building client work on WordPress in 2026, the practical implications of the Phase 3 and 4 delays are:

Collaboration: Build Around It, Not Through It

If your clients need real-time collaborative editing, do not wait for core. Build workflows that accommodate the current limitation: assign clear ownership of pages/posts, use WordPress revisions for version control, and layer collaboration tooling (Google Docs for drafts, then copy into WordPress) until core collaboration arrives. This is not elegant, but it works.

Multilingual: Commit to a Plugin Strategy Now

WPML and Polylang are not going away in the near term. If you have multilingual clients, choose a plugin and build your workflows around it. Core multilingual is a years-away promise. Your clients need functioning multilingual sites today.

Full Site Editing: Invest in the Skill Set

Phase 2 is here and it is not going away. Block themes, the Site Editor, Block Bindings, the Interactivity API, this stack is the future of WordPress development for the next decade. Agencies that have not invested in FSE skill development are building technical debt against their future project capacity. Start now if you have not.

Block Development Is the Core Skill

The job of a WordPress developer who wants to stay relevant over the next five years is block development. Custom blocks built with the @wordpress/scripts toolchain, the Block Bindings API, the Interactivity API, REST API integration, this is the technical surface where WordPress is actively developing and where client projects will increasingly live. At Wbcom Designs, our development team has been investing heavily in this stack, and the difference in delivery quality on modern WordPress projects is significant.

Developer Tools and Ecosystem Maturity in 2026

One dimension of the Gutenberg story that does not get enough attention in roadmap discussions is how substantially the developer tooling around block development has matured. In 2019, building a custom block required either deep familiarity with React and webpack configuration or a steep learning curve with create-block. In 2026, the toolchain is genuinely good.

The @wordpress/scripts package abstracts away most of the build configuration. The create-block scaffold generates a working block with correct structure in seconds. Block linting and type definitions have improved to the point where editors catch most structural errors before runtime. The documentation on developer.wordpress.org, while still imperfect, covers the modern APIs accurately.

The AI angle makes this even more accessible. AI tools can generate syntactically correct block code for standard use cases reliably. A developer who understands the block architecture conceptually can produce working custom blocks faster than was possible even two years ago. The skill floor for custom block development has dropped significantly, which means more plugin developers can ship block-native features without specialized expertise.

This matters for the Gutenberg adoption narrative. The friction of block development was one of the persistent criticisms from the plugin ecosystem. That friction has decreased substantially. More plugins are shipping block features. More themes are built block-first. The network effects of a maturing ecosystem are starting to compound in the way that advocates for the platform always predicted they would.

The Fair Assessment

Project Gutenberg, ten years from its announcement, is a qualified success with an unfinished roadmap.

The qualified success part: WordPress has a modern block editing system, a Full Site Editing architecture, a growing developer toolchain, and an ecosystem that has largely adapted. The project shipped meaningful, hard technology against significant resistance and in a complicated open-source governance environment. That is real.

The unfinished roadmap part: Phase 3 (collaboration) is years behind schedule with no merge date. Phase 4 (multilingual) has not meaningfully started. The governance tensions of 2024 and 2025 cost contributor energy and organizational focus. The AI disruption is changing the premise of what the editor is for faster than the roadmap can adapt.

For developers and agencies, the right frame is not “is Gutenberg done?” It is “what is shipped and stable today, and how should I build on it?” The answer to that question is clear: Phases 1 and 2 are production-ready. Phases 3 and 4 are not. Build accordingly, contribute where you can, and stay connected to the Make WordPress blog and Gutenberg repository for the real ground-level status updates.

The block editor is the WordPress editing experience. That is the enduring outcome of Project Gutenberg, whatever the remaining phases deliver.

AI Tooling and Block Development in 2026

One underreported aspect of Gutenberg’s current state is how well the block editor pairs with AI development tools. Claude Code, GitHub Copilot, and custom MCP servers for WordPress make block development significantly more productive than it was two years ago. The pattern of reading existing block code, generating register_block_type scaffolding, writing JSX that WordPress will parse correctly, and iterating on block attributes is well-supported by current AI models.

This changes the calculus for agencies making skill investment decisions. The initial learning curve for block development was one of the persistent criticisms from developers who had invested years in the classic editor or page builders. AI tooling reduces that curve considerably. A developer who would have needed six months to become productive with Gutenberg block development can now reach a useful working level in a fraction of that time with the right AI-assisted workflow. The new junior-to-senior path for WordPress developers reflects exactly this shift in what skills matter and how quickly they can be acquired.

The agencies that are pulling ahead in block development are the ones who have invested in both the Gutenberg skill set and the AI tooling that makes working within it faster. The combination is multiplicative, not additive. Block patterns, custom block variations, theme.json customization, and the Interactivity API all become more accessible when you have AI tools that understand the WordPress block architecture. Phase 2 of Gutenberg was the platform catching up to developer needs. The current phase, from a practitioner standpoint, is about AI tools catching up to the platform.

Building on WordPress Blocks?

Whether you are planning a new block development project, a site migration to FSE, or a custom plugin that needs deep block editor integration with AI-generated content pipelines or Claude-powered automation, Wbcom Designs has been working inside the Gutenberg ecosystem since Phase 1. We are happy to discuss what your project needs and how the current state of the platform affects your options.