WordPress 7.0 RC4 just hit the servers, and it marks the final “hard string freeze” before we see the stable release on May 20, 2026. If you’ve been following the 7.0 cycle, you know it’s been a bit of a rollercoaster—especially with the decision to pull the full real-time collaboration features for stability. But reaching RC4 means the core team is confident that the remaining bugs are minor.
However, as someone who has spent over a decade fixing sites that “just updated,” let me be clear: WordPress 7.0 RC4 is not for your production site. This is the phase where we break things in staging so we don’t have a 2 AM emergency next week. Specifically, RC4 is about polishing the DataViews API and the new WP AI Client, ensuring they don’t cause race conditions or memory bottlenecks.
Why WordPress 7.0 RC4 Matters for Developers
This release candidate isn’t just another version number. It’s the culmination of massive architectural shifts. We’re moving away from static admin list tables toward a React-based DataViews system. For developers, this means our custom post types are about to get a lot more interactive, but it also means our legacy hooks might need a refactor. Furthermore, the inclusion of the Abilities API changes how we think about AI integration within the block editor.
I previously discussed why WordPress 7.0 real-time collaboration was pulled, and RC4 proves that stability was the right call. The focus now is on ensuring the PHP-only block registration works without a hitch—a feature I’m personally excited about because it lowers the barrier for simple block development without the React overhead.
Technical Testing: The WP-CLI Way
While you can use the Beta Tester plugin, a senior dev knows that WP-CLI is the most reliable way to handle updates in a headless or automated environment. It avoids timeout issues that sometimes plague the browser-based updater during large core shifts. Therefore, use the following command to pull the RC4 build into your local environment:
# Update to WordPress 7.0 RC4 via WP-CLI
wp core update --version=7.0-RC4If you’re building custom functionality that relies on the new version, you might want to wrap your logic in a version check. I’ve seen too many “white screen of death” errors because a developer assumed a feature existed before it was officially merged. Specifically, check the $wp_version global before hitting new APIs.
<?php
/**
* Example: Checking for WordPress 7.0 specific features
*/
function bbioon_check_v7_compatibility() {
global $wp_version;
if ( version_compare( $wp_version, '7.0-RC4', '>=' ) ) {
// Safe to use new DataViews or AI Client logic
}
}
add_action( 'admin_init', 'bbioon_check_v7_compatibility' );What to Watch in the Trac Tickets
If you dig into the Core Trac tickets since May 8, you’ll see a focus on Gutenberg regression fixes. There’s a specific emphasis on how the new Grid block handles mobile reflowing. If you have custom layouts, test your CSS breakpoints against RC4 immediately. In contrast to previous versions, 7.0 is much more aggressive with its native aspect ratio handling.
You can also jump into the WordPress Playground to test these features without even setting up a local server. It’s a great way to verify a quick bug report without the “it works on my machine” headache.
Look, if this WordPress 7.0 RC4 stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
The Final Countdown to Stable
We are just days away from the final release. My advice? Spend tomorrow morning running your most complex site through RC4 on a staging server. Check the wp-content/debug.log for any new deprecation notices. It’s better to fix a transient error now than to refactor an entire plugin on launch day. Consequently, your clients will thank you for the foresight.
