WordPress 7.0 RC1 Testing Playbook: What to Validate Before April

WordPress 7.0 RC1 lands on March 19, 2026, starting a 21-day countdown to the April 9 general availability release. RC1 means feature freeze: no new functionality, only bug fixes. If you followed our WordPress 7.0 beta testing guide, this playbook picks up where that left off — with a structured WordPress 7.0 RC1 testing guide focused on validation, not exploration.

Important: Test on staging environments only; never install RC builds on production sites.

What Changed From Beta to RC1

RC1 is not another beta. Three constraints now apply that did not exist during the beta window:

• Feature freeze. Every commit requires double sign-off from two committers. New features cannot enter the codebase.
• String freeze. No new or changed user-facing text, which means translations can begin and the UI you test now is what ships.
• Bug-fix-only cadence. RC2 (March 26), RC3 (April 2), and a dry run (April 8) follow in weekly intervals. Each release fixes bugs found in the previous one — but those fixes can introduce new regressions.

Beta 1 was delayed one day due to REST autosave controller test failures, real-time collaboration test failures, and client-side media processing backporting. This signals that the editor and collaboration features carry the highest regression risk heading into RC1.

Setting Up Your RC1 Test Environment

Choose the method that fits your workflow:

Method	Best For	Command / Link
WordPress Playground	Quick feature checks (zero setup)	Open in browser
Beta Tester Plugin	Existing staging sites	Settings > Beta Testing > “Beta/RC Only”
WP-CLI	Developers	wp core update --version=7.0-RC1

Verify your environment meets the WordPress 7.0 requirements: PHP 7.4+ (8.3 recommended), MySQL 8.0+ or MariaDB 10.6+. Confirm PHP 7.2 and 7.3 are no longer supported.

The RC1 Test Matrix

This is where the beta guide’s feature exploration becomes structured validation. Test each scenario against your site type and record pass/fail results.

Scenario	What to Test	Pass Criteria	Highest Risk For
Iframed editor	Activate custom blocks; check JS console	Zero console errors; CSS renders inside iframe	Sites with custom blocks, page builders
Real-time collaboration	Open same post in two browsers; edit in both	Edits sync within 30 seconds; no data loss	Multi-author sites, editorial teams
DataViews admin	Navigate Posts/Pages list; check plugin columns	All columns render; filters work; no visual regressions	Sites with admin-modifying plugins
Classic block compat	Insert Classic (freeform) block; test formatting	Block renders correctly; note that RTC is incompatible with Classic block	Sites relying on Classic editor blocks
Caching + RTC	Enable caching plugin; test collaboration polling	Long-poll requests are not cached; edits still sync	Sites running object caching or full-page caching
PHP 7.4 / 8.x	Run Health Check; test all critical paths	No deprecation notices; all pages load cleanly (PHP 8.4 compatibility may need extra attention)	Sites recently migrated from PHP 7.2/7.3

For real-time collaboration setup details, see the real-time collaboration setup guide.

Plugin Compatibility Triage

Not every plugin needs day-one testing. Prioritize by business impact:

P1 — Test immediately (revenue and editor-critical):

• Payment gateways, WooCommerce extensions, membership plugins
• Page builders, custom block plugins, editor-modifying plugins
• Admin-styling and dashboard plugins (DataViews changes break CSS overrides)

P2 — Test in the first week:

• SEO plugins (Yoast, Rank Math)
• Form plugins (Gravity Forms, WPForms)
• Caching plugins (verify they do not cache RTC polling requests)
• Image optimization plugins (may conflict with client-side media processing)

P3 — Test before GA (April 9):

• Analytics, backup, security, and utility plugins

If a P1 plugin fails: Check the plugin’s support forum or changelog for a 7.0 compatibility update. If none exists by RC2 (March 26), contact the developer or plan a workaround before GA.

WooCommerce + RC1: What Store Owners Must Validate

Store owners face a compound upgrade risk: WordPress 7.0 GA ships April 9, followed five days later by WooCommerce 10.7 on April 14, which disables HPOS sync-on-read by default. Custom code writing to wp_posts via wp_update_post() or direct SQL will no longer auto-sync to HPOS on read.

WordPress 7.0 RC1 WooCommerce compatibility test checklist:

• Complete checkout flow (guest and logged-in)
• Payment gateway processing and confirmation
• Admin orders screen (now DataViews-powered)
• Product editor (now running inside an iframe)
• HPOS data integrity (see the HPOS migration checklist)

Store owner timeline:

Date	Milestone	Action
March 19	RC1	Begin staging tests for WP 7.0
March 26	RC2	Re-test with WooCommerce patches
April 2-8	RC3 + Dry Run	Final validation; make go/no-go call
April 9	WP 7.0 GA	Update production if all tests pass
April 14	WC 10.7	Test HPOS change separately on staging

RC1-to-Final Re-Validation Protocol

Testing RC1 once is not enough. Bug fixes between RC releases can introduce new regressions, and plugin developers ship compatibility updates throughout the RC window. Use this cadence to stay current:

Phase	Date	Scope	Time Estimate
RC1	March 19	Full test suite: all test matrix scenarios, all P1 plugins	2-3 hours
RC2	March 26	Re-test any RC1 failures; spot-check critical paths	45-60 min
RC3	April 2	Final spot-check; confirm go/no-go decision	30 min
Dry Run	April 8	Monitor core Trac for last-minute issues	15 min
GA	April 9	Update production during a scheduled maintenance window	—
GA+1 week	April 16	Monitor for WordPress 7.0.1 patch release	Ongoing

Why re-test matters: The Beta 1 delay demonstrated that test failures can surface late. Plugin developers often wait until RC1 to ship compatibility patches. The dry run (April 8) may reveal issues requiring you to delay your production update.

Production Go/No-Go Checklist

Before updating production on April 9, walk through this decision framework. If any item is “No,” delay your update until the issue is resolved. Reference the WordPress 7.0 preparation guide for environment readiness steps.

• All P1 plugins pass on RC3 or later
• No critical errors in the test matrix scenarios
• PHP version meets minimum (7.4+); hosting environment verified
• Full site backup completed (database + files)
• Maintenance window scheduled with rollback plan
• WooCommerce stores: HPOS integrity confirmed; WC 10.7 testing planned separately

One “No” means wait. WordPress 7.0.1 typically ships within 1-2 weeks of GA to address post-launch issues. There is no penalty for waiting.

---

Stay ahead of the WordPress 7.0 release cycle. Subscribe to the Summix newsletter for RC updates, compatibility alerts, and production-readiness checklists as new release candidates drop.