The WordPress 7.0 release process is officially entering its final phase, and if you’ve been around since the 4.x days, you know major version launches aren’t just “another update.” They are logistical marathons. For some reason, the standard advice usually skips the technical grit of what actually happens behind the scenes in the 24 hours leading up to a launch. If you’re managing enterprise-grade sites or complex WooCommerce builds, you can’t afford to be reactive on May 20th.
The 24-Hour Code Freeze: Why It Matters
Specifically, the WordPress 7.0 branch enters a mandatory code freeze following the “Dry Run” on Tuesday, May 19, 2026. During this period, the release squad locks down the source code. Consequently, no changes are allowed unless a literal “blocker” is discovered. If a critical bug appears, the clock resets. We repeat the Dry Run, and the 24-hour freeze starts over. This is the stage where “race conditions” in legacy plugins usually rear their heads.
Release Timeline Overview
- Dry Run: Concluded Tuesday, May 19, 2026, at 21:00 UTC.
- Code Freeze: Currently in effect (no source code changes permitted).
- Release Party: Wednesday, May 20, 2026, at 17:00 UTC in #core Slack.
Testing the WordPress 7.0 Release Process
I’ve seen dozens of developers skip testing on less common server configurations like IIS. Therefore, a key part of the WordPress 7.0 release process involves verifying ZIP packages across diverse environments. Furthermore, since WordPress 7.0 introduces a PHP 7.4 floor and recommends PHP 8.3+, testing your upgrade path on older environments is non-negotiable.
If you want to be proactive, you should be running RC4 or RC5 packages right now. You can use WP-CLI to quickly pull the latest candidate for testing without breaking your workflow.
# Update to the latest WordPress 7.0 Release Candidate via WP-CLI
wp core update --version=7.0-RC4
# Verify the version after update
wp core versionCritical Flows to Validate
Before the release party starts, ensure you’ve tested these specific scenarios. I’ve seen multisite networks fail during minor core updates because of stale transients; a major 7.0 jump is even riskier. Specifically, check if the files listed in $_old_files are actually removed during the upgrade. If they linger, they can cause unpredictable conflicts with the new API hooks.
- Fresh Installs: Manual, WP-CLI, and one-click installers.
- Multisite: Subdirectory vs. subdomain network upgrades.
- User Flows: Publishing blocks, commenting, and site language shifts.
- Plugin Compatibility: Specifically those that hook into the editor or admin UI.
For more technical details on what this version brings, check out my breakdown of WordPress 7.0 AI integration and why the RC5 testing phase was so vital for stability.
Look, if this WordPress 7.0 release process stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Takeaway for Maintainers
The WordPress 7.0 release process is designed for stability, but it relies on community feedback. If you find a bug during the freeze, report it in #core Slack immediately. In contrast to smaller updates, major releases have significantly more steps, and addressing last-minute issues takes time. Don’t wait until the May 20th “Release Party” to find out your custom blocks are broken.
Refer to the Official Major Version Release Process for the full checklist used by the core squad.
