WordPress states that WordPress 7.1 RC2 was also released with applicable fixes from the 7.0.3 security release. Teams already testing RC1 should replace the build, rerun the security-sensitive fixtures, and then repeat their normal plugin, theme, editor, media, REST, cron, email, and transactional regression suite.
Use this for plugin and theme vendors, hosting teams, agencies, QA leads, enterprise publishers, and site owners preparing for the planned WordPress 7.1 final release on August 19, 2026.
Quick answer
Keep RC2 on a disposable or restorable production-shaped staging site. Record the exact build, install it cleanly, verify Core integrity, rerun the 7.0.3 affected-surface fixture, test every critical plugin and theme workflow, inspect logs, restore the rollback snapshot, and repeat the gate on the final release before approving production.
What to check first
- Record RC2 build, PHP, database, object cache, web server, browser, theme, mu-plugin, plugin, and feature-flag versions.
- Isolate staging from production payments, email, analytics, webhooks, search indexing, customer data, and scheduled side effects.
- Rerun login, contributor blocks, Quick Edit, Post Date, custom CSS, multisite registration, comments, feeds, account confirmation, and outbound URL fixtures.
- Exercise custom blocks, editor save and revision, media, REST, cron, email, search, cache, forms, checkout, webhooks, and background jobs.
- Preserve expected result, actual result, logs, screenshots, request IDs, owner, severity, workaround, and final-release retest status.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Security backport | Benign fixtures for each applicable 7.0.3 surface | No disclosure, unsafe markup, privilege expansion, or disallowed request occurs |
| Editorial | Representative roles, blocks, revisions, media, and scheduling | Saved and rendered output matches RC1 baseline or documented change |
| Integration | REST, cron, email, payments, analytics, and webhooks | No duplicate, missing, delayed, or production-directed side effect |
| Recovery | Database and files snapshot | The environment restores cleanly and the fixture can be repeated |
Decision rule
RC2 passes the staging gate only when every required fixture passes or has a documented owner and accepted workaround. It never authorizes an RC build on production.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Clone a production-shaped staging site
- Install and record RC2
- Rerun security fixtures
- Run business-critical regressions
- Restore and schedule final retest
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Clone a production-shaped staging site | Record RC2 build, PHP, database, object cache, web server, browser, theme, mu-plugin, plugin, and feature-flag versions. | The test environment cannot charge, message, index, track, or call production endpoints. |
| Install and record RC2 | Isolate staging from production payments, email, analytics, webhooks, search indexing, customer data, and scheduled side effects. | Every applicable 7.0.3 security fixture has saved evidence on RC2. |
| Rerun security fixtures | Rerun login, contributor blocks, Quick Edit, Post Date, custom CSS, multisite registration, comments, feeds, account confirmation, and outbound URL fixtures. | Critical plugin, theme, editor, REST, cron, email, and transaction workflows pass. |
| Run business-critical regressions | Exercise custom blocks, editor save and revision, media, REST, cron, email, search, cache, forms, checkout, webhooks, and background jobs. | Rollback has been restored successfully and the final-release retest remains scheduled. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp core version --extra
wp core verify-checksums
wp plugin list --fields=name,status,version,update
wp theme list --fields=name,status,version,update
# Attach PHP, browser, REST, cron, email, and webhook evidence to each failed fixture.
Production verification checklist
- The test environment cannot charge, message, index, track, or call production endpoints.
- Every applicable 7.0.3 security fixture has saved evidence on RC2.
- Critical plugin, theme, editor, REST, cron, email, and transaction workflows pass.
- Rollback has been restored successfully and the final-release retest remains scheduled.
Why this usually happens
- A security backport can change sanitization, validation, permission, and rendering paths used by plugins or themes.
- A passing RC1 result does not cover code added or changed in RC2.
- Staging that sends production side effects can create real customer, finance, and analytics damage during testing.
Field notes
- Pin the exact RC2 build in every failure report.
- Use the same fixture data as RC1 so differences are meaningful.
- Keep the final-release retest open even when RC2 passes.
Mistakes to avoid
- Do not install RC2 on a live or mission-critical site.
- Do not reuse an RC1 pass without rerunning the fixture.
- Do not allow staging to send production side effects.
- Do not close compatibility work before testing the final release.
What to tell the client or owner
Share the RC2 build, environment versions, fixture name, expected and actual results, logs, screenshots, request IDs, owner, workaround, rollback result, and final retest date.
Questions teams ask during testing
Why was RC2 released now?
The WordPress 7.0.3 announcement says RC2 was released containing the applicable security fixes.
Is the August 19 final date guaranteed?
It is the planned target and can still change if release blockers require it.
Should a site skip RC2 testing and wait?
Small sites may wait for stable, but vendors and teams with custom integrations gain time by finding regressions now.
When HandL WP should help
HandL WP can build a production-shaped staging fixture, isolate side effects, run WordPress 7.1 RC2 security and integration tests, and document a release decision.
If this is active on a production site, prepare a WordPress 7.1 release gate.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Prove WordPress 7.0.4 patch and upload parity
After the security update, run the WordPress 7.0.4 fleet patch-parity audit across origins, images, workers, and restores, then use the role-based media upload regression test to verify required files and least privilege.
Helpful references