WordPress 7.0 won’t ship on its April 9, 2026 release date. The culprit isn’t bugs or feature polish – it’s a database architecture flaw discovered during Release Candidate testing. The flagship Real-Time Collaboration (RTC) feature, designed to bring Google Docs-style editing to WordPress, disables the platform’s post query caches site-wide whenever someone has the block editor open. The fix requires a dedicated database table to separate collaboration data from permanent post storage. A revised timeline won’t be announced until at least April 22.
The Cache Invalidation Problem
RTC stores sync data in post_meta on a wp_sync_storage post type. Every sync – happening every 1 to 4 seconds – writes to post_meta, which invalidates WordPress’s post query caches across the entire site.
According to WordPress Trac #64696, “objects cached in the post-queries group use the outcome of wp_cache_get_last_changed('posts') to salt their caches, which means that leaving the editor open will effectively prevent the caching of post queries throughout the site.”
The impact extends beyond the user editing. Large sites with millions of post_meta entries see performance degrade site-wide. RTC writes multiple times per second, creating constant cache invalidation. WordPress’s architecture assumes post data is relatively static. RTC breaks that assumption by treating permanent storage like a real-time message queue.
The fix is architectural: a dedicated database table for RTC data, separating “hot” ephemeral syncs from “cold” permanent content. Real-time features aren’t bolt-ons – they require infrastructure rethinking.
Why HTTP Polling Over WebSocket
WordPress chose HTTP polling (4-second intervals when idle, 1 second with collaborators) instead of WebSocket. This seems counterintuitive. WebSocket offers lower latency, persistent connections, and less overhead – objectively better for real-time collaboration.
The constraint is deployment reality. WordPress powers 40% of the web, most installations on shared hosting. Corporate firewalls and proxies routinely block WebSocket traffic. HTTP polling works everywhere. According to WebSocket.org’s comparison, HTTP polling is “easier to deploy using standard HTTP infrastructure” and “works reliably in almost any environment.”
When you’re building a platform, not SaaS, universal compatibility beats bleeding-edge performance. WordPress can’t require VPS-level infrastructure for a core feature. The 1-4 second latency is acceptable for document collaboration, and it runs on any hosting stack that supports HTTP.
CRDTs Solve Conflicts, Create Infrastructure Demands
RTC uses Yjs, a JavaScript CRDT (Conflict-free Replicated Data Type) library. CRDTs eliminate “last write wins” data loss by tracking changes independently and merging them automatically without conflicts. No coordination needed. Apple Notes, Redis, and Cosmos DB use CRDTs for the same reason: simultaneous edits without lockouts.
But CRDTs introduce infrastructure requirements. Constant syncing generates constant writes. That’s where WordPress’s post_meta strategy failed – it wasn’t designed for high-frequency updates. The lesson: CRDTs solve the conflict problem but demand purpose-built storage.
Timeline and What’s Next
WordPress 7.0 was scheduled for April 9, 2026 at WordCamp Asia. On March 31, the core team delayed it after testing revealed the cache issue. According to WordPress Developer News, “pre-release versions are paused until April 17th, at which point the release squad and project leadership will have enough context to set a new schedule, to be announced no later than April 22nd.”
The expected release is mid-to-late May 2026. Matt Mullenweg authorized the dedicated table architecture after testing exposed the performance impact. This shows maturity: ship stable software, not broken features on arbitrary deadlines.
What Developers Should Know
When WordPress 7.0 launches, RTC will enable multi-user block editor collaboration with real-time selection highlighting. But developers need to understand the performance profile. Test with multiple concurrent editors on staging. Monitor the new RTC table’s database size. Check plugin compatibility – legacy meta boxes disable collaboration entirely to prevent unsynced writes.
For hosting: shared hosting should handle HTTP polling fine, but VPS or dedicated servers will perform better under heavy concurrent load. Plugin developers should use Yjs-synchronized stores instead of local state that bypasses the CRDT merge logic.
The broader takeaway: real-time collaboration isn’t “just add a feature.” It requires dedicated infrastructure for hot data, architecture trade-offs between compatibility and performance, and caching strategy redesigns. WordPress’s delay is a reminder that platforms face different constraints than SaaS products, and getting it right beats shipping on time.
