WordPress 7.0 RTC was the marquee feature, the one everyone was waiting for. But if you’ve been watching the Trac tickets, you saw the crash coming. Last week’s Dev Chat confirmed what many of us feared: Real-Time Collaboration has been pulled from the 7.0 release. Consequently, the upcoming RC3 is essentially a pivot back to a “New Beta 1.”
I’ve seen this movie before. We get excited about a “Google Docs style” editing experience, and then the architectural reality hits. Specifically, ticket #64696 revealed that the current RTC implementation was effectively killing persistent caching for WP_Query. For a high-traffic site, that is a death sentence. Therefore, removing it wasn’t just a choice; it was a necessity for core stability.
The Bottleneck: Why WordPress 7.0 RTC Failed the Gate
The core issue wasn’t just UI glitches. It was a race condition nightmare. When multiple users hit the same post, the frequency of updates created massive server load and memory efficiency problems. Fuzz testing surfaced recurring bugs that simply couldn’t be patched in time for a May 20th ship date. Furthermore, the persistent cache for WP_Query was being bypassed whenever the editor was open, leading to massive TTFB regressions.
If you were following my previous breakdown on WordPress 7.0 RC3 stability, you know I’ve been skeptical. Building RTC on top of a legacy database schema is like trying to install a turbocharger on a 1998 Corolla without upgrading the brakes. It works in the driveway, but it’ll fall apart on the highway.
The Custom Table Debate
One interesting takeaway from the chat was the discussion around the RTC custom table. Joefusco brought up a valid point: where is the gate for system team feedback on schema changes? WordPress core rarely introduces new tables because of the technical debt they create. However, for a feature as complex as RTC, a dedicated table was the only sane approach. Here is a conceptual look at 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 a more positive note, there is a new proposal to auto-generate Block Editor Handbook docs from block.json. This is a massive win for DX (Developer Experience). If you’ve ever had to hunt through outdated Gutenberg docs, you know the frustration. By using block.json as the single source of truth, we finally get documentation that stays in sync with the code.
Look, if this WordPress 7.0 RTC stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Takeaway
The removal of RTC from the WordPress 7.0 release is a blow to the “Phase 3” hype, but a victory for site owners who value performance. We still have 37 open tickets in the 7.0 milestone, and the team is running a dedicated scrub to clear the deck. For now, stick to stable third-party solutions if your clients need collaborative editing. Don’t hack core to bring it back; you’ll regret it when the official API finally drops in 7.1 or later.
For more technical details, keep an eye on Ticket #64696 on the official Trac.
