WordPress 7.0 is delayed and RC3 is basically a beta

Data center server racks illustrating the storage layer scaling behind WordPress 7.0

The WordPress 7.0 Release cycle has gone off the usual script. If you follow the dev chat agendas, you already know it. Normally, by the time we hit Release Candidate 3 (RC3), we are polishing CSS and double-checking translations. This Friday’s RC3 is closer to a new Beta 1.

I have spent 14 years watching WordPress evolve, and a delay is annoying when you have project timelines to hit, but this one had to happen. The core team is wrestling with the storage layer for Real-Time Collaboration (RTC). In early testing, the implementation fired close to 4,000 SQL queries in two minutes of editing. That would melt most shared hosting.

The real-time collaboration storage bottleneck

The original plan was to store collaborative events in post meta. On paper that is reasonable, since it is a standard hook-heavy system everyone already knows. At scale it falls apart. The team is now benchmarking custom database tables and transients for the high-frequency syncing RTC needs, along with a hybrid approach that keeps data integrity without killing server performance.

That is why the WordPress 7.0 RC3 stability focus matters. The release date slips, and in exchange the site does not fall over when two editors open the same post.

Proposal: auto-generated docs from block.json

The May 6 agenda also carries a proposal to auto-generate Block Editor Handbook docs from block.json. As a dev who has written thousands of lines of documentation, I want this. We already define our attributes, titles and supports in block.json, so updating the handbook by hand is duplicate work, and duplicate work is how docs go stale.

This is how you can read that metadata in PHP today. A documentation parser would use roughly the same logic:

<?php
/**
 * Simple demonstration of parsing block.json for metadata.
 * Prefixing with bbioon_ for safety.
 */
function bbioon_get_block_metadata( $block_type_name ) {
    $registry = WP_Block_Type_Registry::get_instance();
    $block_type = $registry->get_registered( $block_type_name );

    if ( ! $block_type ) {
        return null;
    }

    // Accessing the raw attributes defined in block.json
    return $block_type->attributes;
}

// Usage: bbioon_get_block_metadata( 'core/paragraph' );

What this means for your production sites

If you run high-traffic sites, pushing the WordPress 7.0 Release back to May 20, 2026 is good news. The Presence API testing that hosts like Bluehost and Kinsta are running is where the race conditions get found, instead of you debugging them on a live client site at 2 AM.

If the 7.0 upgrade is eating your dev hours, I can take it on. I have been wrestling with WordPress since the 4.x days.

Why I am not deploying 7.0 yet

This is an unusual cycle, where the version numbers RC3 and RC4 are really markers for beta progress. I would not put 7.0 on production until the RTC benchmarks are settled and the Presence API has proved it can take the load. The official dev chat agenda has the latest on the May 8th RC3 release.

author avatar
Ahmad Wael
I'm a WordPress and WooCommerce developer with 15+ years of experience building custom e-commerce solutions and plugins. I specialize in PHP development, following WordPress coding standards to deliver clean, maintainable code. Currently, I'm exploring AI and e-commerce by building multi-agent systems and SaaS products that integrate technologies like Google Gemini API with WordPress platforms, approaching every project with a commitment to performance, security, and exceptional user experience.