WordPress 7.0 will not ship with real-time collaboration, and honestly I think that was the right call. Not because the idea is bad — collaborative editing in the block editor would be genuinely useful — but because shipping it well across every kind of WordPress install is a much harder problem than it looks.
On 8 May 2026, the Make WordPress Core team announced that real-time collaboration was being removed from WordPress 7.0. The reasons cited — surface area, race conditions, server load, memory efficiency, and recurring bugs surfaced through fuzz testing — are exactly the kind of thing you want a piece of software running 40% of the web to take seriously.
Kahunam’s earlier overview of what was expected in WordPress 7.0 is useful background for understanding how quickly release scope can change.
The hosting problem nobody talks about
WordPress might be the only piece of software in the world that often runs on both a shared tiny overloaded server (for £1 a month resold multiple times via eBay) and also on a maxed-out EC2 instance behind a CDN for an enterprise client. The hosting environments and capabilities WordPress has to support are wildly different, and any new Core feature has to behave acceptably on all of them.
Real-time collaboration is unusually resource-intensive. Every keystroke needs to sync. Every cursor position needs to broadcast. Conflicts need to be resolved consistently across clients. The transport layer, the storage model, the cache invalidation — all of it has to be reliable on a shared host where MySQL is already under pressure, AND fast enough that the experience feels good on an enterprise setup with hundreds of editors.
Trying to build a one-size-fits-all version of that is genuinely a remarkable engineering challenge. Not a minor one. A real one.
Stability beats feature hype
Real-time collaboration is attractive. Anyone who has used Google Docs understands the appeal: multiple people editing together, visible selections, fewer content handover bottlenecks.
But WordPress is not a single hosted document editor. It runs across many hosting environments, themes, plugins, page builders, custom blocks, caching setups, security tools, and editorial workflows.
A feature that works well in one controlled demo can still be risky when it has to behave safely across millions of different sites.
For a small business, the issue is not whether collaboration sounds useful. It is whether a new editing feature could make publishing less reliable, increase server load, or create strange conflicts with existing plugins.
What the decision tells site owners
The useful lesson is not ‘avoid new WordPress features’. The lesson is ‘enable new features with judgement’.
When a feature touches editing, database writes, concurrent users, and hosting performance, it deserves careful rollout. That is true for Core features, page builder updates, AI tools, ecommerce plugins, and custom admin workflows.
Before enabling a major editor feature, ask:
- Does it affect how content is saved?
- Does it change database behaviour?
- Does it increase background requests or server load?
- Does it interact with custom blocks, meta boxes, or page builder components?
- Can we test it on staging with real content?
- Is there a rollback plan?
Those questions are dull. They are also what keep production websites stable.
Credit where it’s due
Pulling a headline feature this close to release is not a fun decision to make, and the people who built and tested this work deserve a lot of respect for being honest about where it was.
A few names worth calling out:
- Kevin Jahns, whose Yjs CRDT library is the foundation the WordPress collaboration work was built on. CRDTs are not easy, and Yjs is the reason this conversation is even possible.
- Anne McCarthy (@annezazu), who has been the steady public voice through every Phase 3 update — including the one that announced this wasn’t shipping.
- The Automattic / WordPress VIP team, who built a working RTC implementation that fed into the Core effort.
- The peer reviewers and testers — Max Schmeling, Ankit K Gupta, Chris Zarate, Aditya Shah, Courtney Robertson — who did the unglamorous work of stress-testing this across real hosting setups and surfacing the issues that ultimately drove the decision.
And to everyone else who contributed code, ran fuzz tests, filed bug reports, or argued the trade-offs in Slack and Trac — thank you. Walking away from something you’ve poured work into takes discipline.
Feature cuts are not always bad news
It is easy to read a removed feature as failure. In this case, the stronger interpretation is that WordPress Core chose reliability over a headline feature.
The Make WordPress Core post says work will continue after the immediate release work is complete, with broader testing and continued iteration for a future release. That is a better path than shipping a fragile feature and asking site owners to absorb the disruption.
For SMEs, the same principle applies to your own website backlog. Do not add live chat, AI content tools, complex forms, booking systems, or page builder experiments simply because they are available. Add them when they are useful, tested, supportable, and proportionate to the business value.
The practical takeaway
WordPress 7.0 dropping real-time collaboration is not a reason to panic. It is a reminder that mature software sometimes says no, or not yet.
For business sites, that is reassuring. The feature can keep improving, but production sites need stable editing, predictable hosting behaviour, and fewer surprises. A delayed feature is better than a rushed one that breaks the workflow your team relies on.
Author
