What WordPress 7.0 Didn't Ship, And Why That's the Real Story

On May 20, 2026, WordPress 7.0 “Armstrong” shipped. The release notes are long. The blog posts about it will be longer. By next Tuesday there will be three hundred listicles ranking the new blocks, half a dozen hot takes on what AI in core means for the future of publishing, and at least one hosting company telling you that upgrading right now is both urgent and risk-free.

This post is about none of those things.

The most interesting decision in WordPress 7.0 was made on May 8, twelve days before the release. The core team removed real-time collaborative editing from the release. This was the feature the entire 7.0 cycle had been organized around. It was the reason the release date had already slipped from April 9 to May 20. They cut it anyway.

That decision is the actual story. Here is why it matters.

What 7.0 is, briefly

Some background. WordPress 7.0 is named “Armstrong”, continuing the jazz musician naming tradition that started with 1.0 “Miles” in January 2004. By the count of the release announcement it is the thirtieth major version since that beginning. The release came together with contributions from more than 875 people, over two hundred of them shipping their first WordPress patch, with release lead Matias Ventura coordinating the cycle.

The original release date was April 9, 2026, pegged to Contributor Day at WordCamp Asia. That date was a calendar event, not a code event, and when contributors looked at where the architecture actually stood, they decided the date was wrong. The release was pushed to May 20.

The whole 7.0 release was framed publicly as two things. The first was a foundation for AI inside WordPress. The second was the long-awaited arrival of real-time collaborative editing. Both featured prominently in the roadmap, the developer blog, and the marketing.

Then the second one disappeared, less than two weeks before launch.

What real-time collaboration was supposed to be

Real-time collaboration in WordPress was not a small feature. It was an architecture change, the kind of change that gets discussed for years before a single commit lands. The version that was supposed to ship in 7.0 had been actively in development across multiple Gutenberg cycles and had absorbed serious engineering attention from contributors at Automattic, hosting companies, and the wider community.

The promised behaviour was familiar to anyone who has used Google Docs or Figma. Multiple users would be able to edit the same post or page at the same time. Their changes would synchronize as block content moved through the editor. Offline edits would reconcile when a user reconnected. The Notes feature, which had been quietly upgraded across the cycle, would gain its own real-time sync and an inline keyboard shortcut for adding comments.

The plan even included a thoughtful compromise for the long tail of WordPress hosting. To avoid melting cheap shared hosting plans, the default would have been HTTP polling with a built-in two-user limit per post. WebSocket support was structured as a hook, so hosts and plugins could ship higher-throughput sync providers without forking core. Larger editorial teams could lift the concurrent-user ceiling through wp-config.php.

In other words, this was not an experimental preview being marked as beta in the corner of the dashboard. It was the headline feature, with a production-ready story for the small-business installations that make up most of the WordPress universe.

It is sitting on a branch now, waiting for a future release. That is the literal status. It is everything else around that status that is interesting.

Why it was pulled

The official line, on the May 8 post on the WordPress developer blog, was that performance and bug regressions during the release candidate phase made the feature unsafe to ship. Read between those polite words and you can guess what the testing matrix looked like.

Real-time sync across a content management system that runs on a few billion sites is a problem with no clean shape. The same block editor has to behave on a developer’s laptop in Berlin, a budget shared host in Mumbai, an enterprise managed platform in San Francisco, and the woodworking blog of a retiree in Ohio who has not run the auto-updater in eighteen months. The set of network conditions, plugin combinations, and editor extensions is essentially unbounded.

The polling fallback was supposed to handle the worst of that, but a polling sync layer that scales gracefully across that many environments is harder than it looks. Conflict resolution between offline edits and live edits is harder still. Hooks into WebSocket providers introduce a new failure mode every time a host implementation is slightly out of spec. None of these are theoretical problems. They are the kind of problems that, in production, surface as data loss complaints from a small but extremely vocal slice of users who happen to be the publishers building serious content workflows.

The team had a choice. They could ship something that mostly worked, accept that the first three minor releases of the 7.x cycle would be a fire drill of patches, and let the broader story about collaboration become a story about regressions. Or they could pull the feature, ship the rest of the release stable, and finish the work without a public clock running against them.

They pulled it.

The unusual part

In the commercial software culture of 2026, that decision is unusual to the point of being countercultural.

The default playbook, refined across two decades of venture-backed software releases, is to ship the announced feature on the announced day, mark it beta or “public preview” if necessary, and harvest the marketing benefit while engineering catches up in the next two quarters. The press release does not change. The roadmap slide does not change. The keynote happens. The fact that the feature is brittle is absorbed into the product backlog and rebranded as iteration.

WordPress did the opposite, and it did so without much fanfare. The May 8 post was technical, restrained, and short. There was no apology tour, no insistence that this was actually a good thing in disguise, no roadmap reshuffle dressed up as strategy. Just a note that the feature was not ready, an acknowledgment of the work done by contributors, and a commitment to keep building it.

There is a deeper continuity here. WordPress has been doing this for a long time. The Gutenberg block editor itself, which is now the basis of the entire publishing experience, went through years of public iteration in a plugin before it was merged into core in WP 5.0 at the end of 2018. The Site Editor took the same long road. Block themes did too. The pattern is consistent across the project’s history. The core team prefers to be late and stable rather than early and brittle, and they prefer to do so quietly.

That preference is not free. The opportunity cost is real. Press attention drifts to platforms that announce more aggressively. Some users and some hosts move to alternatives because they want collaborative editing now and cannot wait. Some contributors burn out building the cut feature.

The choice to absorb those costs, rather than push the costs onto users running production sites, is the actual culture of WordPress core. It is the thing you are buying into when you build on the platform.

What did ship

What did ship in 7.0 is worth noting briefly, because it is genuinely useful and because it is the part of the release the rest of the internet will cover at length.

The admin dashboard got a substantial modernization. DataViews, a React-based replacement for the static admin list tables that have been part of WordPress since the early years, is now standard. It brings dynamic filtering, configurable views, and a foundation that the rest of the admin will be ported onto across the 7.x line.

The block editor gained a visual revisions screen with colour-coded diff highlighting, which is the kind of small ergonomic improvement that quietly changes how often people use revisions at all. Two new core blocks shipped, Icon and Breadcrumbs, both filling long-standing gaps. Pattern editing was refocused around content. Navigation menus gained mobile overlays with proper styling control.

For developers, server-side block registration arrived. Blocks can now be registered in PHP with auto-generated inspector controls, which dramatically reduces the JavaScript footprint required to ship a functional block. This is a meaningful change for any team building custom blocks for client sites.

And then there is the AI part, which deserves its own paragraph.

On the AI in WordPress 7.0

The Web Client AI API and the related Abilities API are the parts of the release that will be most aggressively misrepresented over the next few weeks. The headline you will see is some variation of “WordPress now has AI”. That headline is wrong in a specific and important way.

WordPress 7.0 does not include an AI model. It includes a standardized interface for plugins and themes to connect to external AI providers. The model itself, whoever runs it, stays outside core. The Connectors API lets any plugin register a provider. The Client Side Abilities API exposes browser-side capabilities that those providers can call into.

What this means in practice for a site you actually operate is that you still have to choose a provider, sign a contract with them, pay for tokens, manage API keys, and consider the regulatory implications of routing your content through their servers. None of that is solved by 7.0. What is solved is the integration plumbing, which is genuinely useful and was overdue.

The hype framing makes this feature sound bigger than it is. The honest framing makes it sound more useful than the hype. We will go deeper on the practical implications in a separate post.

If you run a WordPress site for real work

For anyone running a real client site on WordPress, the short version of the upgrade advice is the same as it always has been, which is to say boring on purpose.

Do not upgrade production on the first weekend. The 7.0 to 7.0.1 gap is when bugs that survived the release candidate phase tend to surface. Wait for one minor release, ideally two, before touching anything that takes payments or accepts user submissions.

Check plugin compatibility before doing anything else. The DataViews change in particular will affect any plugin that hooks into the admin tables, and there will be plugins that have not been updated since their last vendor pivot. Block editor extensions are another likely friction point. If you use a page builder that fights with Gutenberg, you already know the drill.

Test the upgrade on a staging environment that matches production, including the PHP version, the database, and the active plugin set. We have been doing WordPress work for more than a decade, and the single most useful sentence in any upgrade discussion is still “staged it, no surprises, ready to push”. If you cannot say that sentence, do not upgrade yet.

Closing

The reason any of this is worth a long post is that the decision to pull real-time collaboration from WordPress 7.0 is a small, public, real-world example of engineering discipline in a corner of the industry where discipline is rare. The team chose to ship something stable and explain themselves, instead of shipping something brittle and apologizing later.

You can build on platforms where the engineering culture works that way. You can also build on platforms where it does not. Knowing the difference is part of the job.