WordPress 7.0 RTC was the headline feature, the one everyone had been waiting for. If you have been watching the Trac tickets, though, you saw this coming. Last week’s Dev Chat confirmed what a lot of us feared: Real-Time Collaboration has been pulled from the 7.0 release. That turns the upcoming RC3 into what is basically a new Beta 1.
I have seen this movie before. Everyone gets excited about a “Google Docs style” editing experience, then the architectural reality lands. Ticket #64696 showed that the current RTC implementation was effectively killing persistent caching for WP_Query. On a high-traffic site, that is a death sentence. Pulling it was less a choice than a requirement for core stability.
The bottleneck: why WordPress 7.0 RTC failed the gate
The core problem went well beyond UI glitches. It was a race condition nightmare: when several users opened the same post, the update frequency piled on server load and memory pressure. Fuzz testing kept surfacing bugs that could not be patched in time for a May 20th ship date. On top of that, the persistent cache for WP_Query got bypassed whenever the editor was open, which caused large TTFB regressions.
If you read my earlier breakdown on WordPress 7.0 RC3 stability, you know I have been skeptical. Building RTC on a legacy database schema is like bolting a turbocharger onto a 1998 Corolla without touching the brakes. It is fine in the driveway, but it will come apart on the highway.
The custom table debate
One thing that stuck with me from the chat was the debate over the RTC custom table. Joefusco raised a fair point: where is the gate for system team feedback on schema changes? WordPress core rarely adds new tables because of the technical debt they bring. For something as complex as RTC, though, a dedicated table was the only sane option. Here is a rough idea of how a simplified RTC presence check might have looked in PHP:
<?php
/**
* Conceptual check for RTC support in WordPress 7.0
* Note: This was pulled from core, but similar logic exists in the testing plugin.
*/
function bbioon_check_rtc_availability() {
// Check if the presence API is active
if ( ! function_exists( 'get_current_screen' ) ) {
return false;
}
$screen = get_current_screen();
// In the old 7.0-beta paths, we checked for global RTC flags
// which are now being reverted or moved to transients.
$is_rtc_enabled = apply_filters( 'bbioon_enable_rtc_override', false );
if ( $is_rtc_enabled ) {
// This is where the race conditions lived.
// Multiple users hitting the same post_id frequently.
return true;
}
return false;
}
Documentation and the future of block.json
On the brighter side, there is a new proposal to auto-generate Block Editor Handbook docs from block.json. That would be a real win for developer experience. Anyone who has dug through outdated Gutenberg docs knows the frustration. Using block.json as the single source of truth finally gives us documentation that stays in sync with the code.
If this WordPress 7.0 RTC mess is eating your dev hours, hand it to me. I have been wrestling with WordPress since the 4.x days.
Final takeaway
Pulling RTC from the WordPress 7.0 release stings if you bought into the “Phase 3” hype, but it is good news for site owners who care about performance. There are still 37 open tickets in the 7.0 milestone, and the team is running a dedicated scrub to clear them. For now, stick to stable third-party tools if your clients need collaborative editing. Do not hack core to force it back in. You will regret it when the official API lands in 7.1 or later.
For more technical details, keep an eye on Ticket #64696 on the official Trac.
