WordPress 7.0 Release Candidate 2 is ready for testing
The second release candidate for WordPress 7.0 is available and intended for validation on non‑production environments. Read the official announcement at WordPress 7.0 Release Candidate 2.
RC builds are treated as “release-ready” from a packaging perspective, but this stage exists to flush out remaining defects, regressions, and hosting or plugin edge cases before the final tag is cut.
Do not install RC2 on production or mission‑critical sites. Use a staging site, a dedicated test server, or an isolated local environment so that crash reports and recovery steps can be captured without business impact.
Release timing and what RC2 represents
RC2 sits late in the 7.0 release cycle, with the planned final release scheduled for .
At this point, attention shifts from feature delivery to stability: upgrade paths, backwards compatibility, REST and admin behaviour, editor interactions, caching behaviour, and hosting-specific quirks under real traffic patterns.
RC2 also aligns with a “hard string freeze”, which means UI text should now be stable so translation teams can finish language packs without strings changing underneath them.
How to test WordPress 7.0 RC2 without risking production
Choose a method that matches your workflow, then focus on upgrades, critical journeys, and compatibility checks.
Beta Tester plugin (controlled update stream)
Install and activate the WordPress Beta Tester plugin on a test site, then select the “Bleeding edge” channel with the “Beta/RC Only” stream. This approach is useful when you want repeatable updates via the dashboard while keeping the environment close to a typical client site.
Direct download (zip install on a sandbox)
Download and install the RC2 zip on a non‑production WordPress instance when you want a clean, deterministic package to test upgrade, file integrity, and deployment routines used by your team.
WP‑CLI (fast, scriptable upgrades)
Update via command line to validate automation, provisioning scripts, and CI pipelines using: wp core update --version=7.0-rc2. This is especially useful for hosts and agencies that manage fleets of sites and need confidence in repeatable upgrades.
WordPress Playground (browser-based validation)
Use WordPress Playground to test directly in your browser with no setup. It is well-suited to quick editor and UI checks, reproduction of reported issues, and fast comparisons between builds.
What to focus on during RC2 testing
RC2 testing is most valuable when it mirrors real site behaviour: upgrades, editor workflows, and plugin/theme interoperability.
Prioritise the upgrade process first. Validate that database upgrades complete cleanly, that site health remains stable, and that recovery mode is not triggered by known-good plugin sets.
Exercise new and changed capabilities highlighted during the 7.0 beta cycle, then verify that existing editorial workflows behave the same way under the block editor, classic editor (where installed), REST endpoints, scheduled posts, and media handling.
The project also calls out targeted areas for exploration, including real-time collaboration and pattern editing with content-only interactivity, where subtle UX or permission issues can surface late.
Theme, plugin, and hosting readiness
Compatibility work done now prevents breakage and support load once 7.0 ships.
Plugin and theme authors should run their full regression suites against 7.0 RC2, then complete final fixes and update the “Tested up to” value to 7.0 once validation is complete. Pay particular attention to editor-facing features, block registration, deprecated APIs, and any code that assumes older core behaviour.
Hosts and infrastructure teams should test on their own platforms to confirm PHP/MySQL/MariaDB combinations, object caching layers, page caching strategies, and update mechanisms behave correctly. Distributed hosting tests help catch issues that do not reproduce on a single machine, such as persistent object cache inconsistencies and network filesystem edge cases.
Reporting issues and contributing signal
Good bug reports accelerate fixes by making problems reproducible and measurable.
If you find an issue, report it in the Alpha/Beta area of the support forums, or file it in WordPress Trac if you can provide a clear reproduction path. Include steps, expected outcome, actual outcome, environment details, and whether the issue is a regression from a stable version.
Keep an eye on core development updates through Make WordPress Core posts as RC2 feedback is triaged and changes continue to land towards the final release.
FAQ: WordPress 7.0 RC2 testing
Quick answers for developers, site owners, and infrastructure teams validating RC2.
Can I install WordPress 7.0 RC2 on a live site?
No. RC2 is pre-release software and should not be used on production or mission-critical websites. Use staging, a test server, local development, or WordPress Playground.
What is the fastest way to update a test site to RC2?
WP-CLI is typically fastest and easiest to automate: wp core update --version=7.0-rc2.
When is the final release of WordPress 7.0 scheduled?
The planned final release date is .
What should I test first as an agency or site maintainer?
Test the upgrade path, then core user journeys such as editing and publishing, media uploads, login and permissions, and site-specific plugin workflows. Confirm no regressions under your caching and security stack.
I maintain a plugin or theme. What should I do before 7.0 ships?
Run compatibility testing against 7.0 RC2, fix any breakage, and once verified, update your readme “Tested up to” field to 7.0 so users and automated tooling can assess readiness.
Why does RC2 matter if release candidates are “ready”?
“Ready” means the project believes the release can ship, but real-world testing across diverse hosting stacks and plugin combinations is what confirms stability and catches late regressions.
