WordPress 7.1 Release Candidate 1 became available on August 5, 2026, with more than 145 updates and fixes since Beta 4. A release candidate is close to final, but WordPress still tells teams not to install it on production or mission-critical sites. The useful next step is a controlled staging gate that proves business workflows and produces rollback evidence.
Use this for agencies, plugin and theme teams, WooCommerce stores, publishers, membership sites, and site owners preparing for the planned WordPress 7.1 release on August 19, 2026.
Quick answer
Keep production on the current stable WordPress release. Clone representative data into a protected staging environment, install RC1 there, run a written fixture across editor, frontend, REST, cron, email, login, forms, and commerce, then record pass, fail, owner, and rollback evidence. Recheck the same matrix when the final build ships.
What to check first
- Confirm the test site is isolated from production payments, email, webhooks, search indexing, and customer accounts.
- Record WordPress, PHP, database, theme, must-use plugin, and active plugin versions before the upgrade.
- Test the block editor, Site Editor, media uploads, revisions, scheduled publishing, REST endpoints, cron, and authentication.
- Run the site's real revenue and lead paths, including checkout, subscriptions, forms, consent, thank-you pages, and conversion events.
- Prepare a restore point and a written rollback trigger before changing the staging build.
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 |
|---|
| Editorial | Create, revise, preview, schedule, and publish a representative post | Content, revisions, permissions, and scheduled events behave as expected |
| Commerce | Guest and logged-in checkout with sandbox payment methods | Totals, stock, order status, emails, and webhooks remain correct |
| Integration | REST, cron, forms, SMTP, analytics, and consent fixtures | No new errors, missing requests, duplicate events, or permission changes |
| Rollback | Restore the database and files on a disposable copy | The documented recovery procedure completes inside the approved window |
Decision rule
Hold the production upgrade when a critical workflow fails, a new PHP or JavaScript error appears, permissions broaden, database work cannot be rolled back, or the team cannot explain a changed result. RC1 passing does not authorize 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.
- Build an isolated staging copy
- Capture the version inventory
- Run critical workflow fixtures
- Triage every new error
- Approve or hold with evidence
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Build an isolated staging copy | Confirm the test site is isolated from production payments, email, webhooks, search indexing, and customer accounts. | The staging environment cannot charge customers, send production messages, or receive production webhooks. |
| Capture the version inventory | Record WordPress, PHP, database, theme, must-use plugin, and active plugin versions before the upgrade. | Every critical fixture has an expected result, actual result, evidence link, and owner. |
| Run critical workflow fixtures | Test the block editor, Site Editor, media uploads, revisions, scheduled publishing, REST endpoints, cron, and authentication. | No unexplained errors appear in PHP, browser, REST, cron, email, or payment logs. |
| Triage every new error | Run the site's real revenue and lead paths, including checkout, subscriptions, forms, consent, thank-you pages, and conversion events. | The rollback restore has been tested and the final-release retest is scheduled. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
# Record the build before testing
wp core version
wp plugin list --format=csv
wp theme list --format=csv
wp cron event list --fields=hook,next_run_relative,recurrence
wp core verify-checksums
# Keep production on the current stable release until WordPress 7.1 final.
Production verification checklist
- The staging environment cannot charge customers, send production messages, or receive production webhooks.
- Every critical fixture has an expected result, actual result, evidence link, and owner.
- No unexplained errors appear in PHP, browser, REST, cron, email, or payment logs.
- The rollback restore has been tested and the final-release retest is scheduled.
Why this usually happens
- A release candidate contains the intended final feature set, but late fixes can still alter behavior before general release.
- Plugin compatibility labels do not exercise a site's custom code, data, cache, or third-party integrations.
- A visual homepage check misses background failures in cron, email, REST, webhooks, permissions, and analytics.
Field notes
- Use anonymized production-shaped data so role, order, taxonomy, and media edge cases are represented.
- Capture browser console, PHP log, REST response, network trace, and user-visible result for each failed row.
- Treat a clean test as evidence for the tested build and fixture, not a guarantee for later builds.
Mistakes to avoid
- Do not install RC1 on a live or mission-critical site.
- Do not approve the release after checking only wp-admin and the homepage.
- Do not let staging send real email, payments, analytics, or webhooks.
- Do not replace evidence with a plugin compatibility badge.
What to tell the client or owner
Share the staging URL, RC build, PHP version, failing fixture, expected result, actual result, logs, request trace, screenshots, affected role, and rollback status.
Questions teams ask during testing
Is WordPress 7.1 RC1 safe for production?
No. WordPress explicitly recommends using it only on test sites because it remains under development.
When is WordPress 7.1 final planned?
The RC1 announcement lists August 19, 2026 as the planned final release date.
Should a site that passed Beta 4 retest RC1?
Yes. RC1 includes more than 145 updates and fixes since Beta 4, so the critical fixture should be rerun.
When HandL WP should help
HandL WP can build a production-shaped staging fixture, test WordPress 7.1 against custom themes and plugins, inspect background integrations, and document a release or hold 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.
Rerun the gate on WordPress 7.1 RC2
Use the WordPress 7.1 RC2 security fix regression test to rerun applicable WordPress 7.0.3 fixtures and the full production-shaped integration suite on staging.
Complete the WordPress 7.1 release-candidate gate
Build a WordPress 7.1 RC2 plugin and theme vendor support matrix, then run the RC2 block sanitization compatibility test against real saved content, roles, REST updates, unsafe fixtures, and front-end output.
Move the WordPress 7.1 test lane to RC3
Use the WordPress 7.1 RC3 security-backport gate, translate the candidate's change volume through the RC3 risk-based regression matrix, and compare critical requests with the RC3 Query Monitor baseline workflow before final-release approval.
Add the WordPress 7.1 accessibility production checks
Test the documented media-library preference with the WordPress 7.1 infinite-scroll accessibility opt-out workflow, validate plugin controls through the accessible tooltip regression test, verify custom admin tables with the list-table screen reader matrix, and give editors the decorative Image block decision workflow.
Helpful references