WordPress 7.1 RC3 was published after the 7.0.4 security release and includes the security fix in the release-candidate line. That makes it an important retest point for teams already evaluating 7.1. It does not make RC3 a production release. The gate should isolate the security-sensitive media path while repeating the broader business workflows that can regress between candidates.
Use this for plugin and theme teams, agencies, managed hosts, product owners, and site operators preparing for the scheduled WordPress 7.1 final release.
Quick answer
Refresh a production-like staging copy, install RC3 there, confirm the security backport baseline, and run a written matrix for login, roles, media, editors, REST, cron, cache, search, forms, checkout, email, and custom integrations. Record each result against RC2 or the current production baseline. Hold production until the final release and a short post-release validation window.
What to check first
- Record RC3 build, PHP, database, web server, object cache, Imagick, Ghostscript, plugin, theme, and mu-plugin versions.
- Clone representative content and configuration without exposing customer secrets or live callbacks.
- Define business-critical journeys and security boundaries before the candidate is installed.
- Run the same fixtures against the current production baseline and RC3 so changed behavior is measurable.
- Assign owner, severity, workaround, rollback point, and retest status to every failure.
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 baseline | Author media fixtures and package inventory | Patched behavior with normal derivatives |
| Publishing | Block, classic, scheduled, reusable, and custom content | No content or timing regression |
| Commerce and leads | Checkout, forms, email, webhooks, and consent | Stable IDs and one business outcome |
| Operations | REST, cron, cache purge, backups, and CLI | Expected status, timing, and logs |
Decision rule
RC3 can clear the test lane when all critical journeys pass, security boundaries are intact, failures have owners, and rollback is proven. Production remains held for WordPress 7.1 final and a final-package verification.
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.
- Reproduce each failure with one stable fixture and the smallest plugin or theme scope.
- Capture logs, request data, screenshots, and the first known differing build.
- Report core regressions with reproducible steps and move plugin issues to the correct vendor.
- Apply only reversible staging workarounds while the candidate is under review.
- Repeat failed and adjacent tests after any new candidate or final package.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Reproduce each failure with one stable fixture and the smallest plugin or theme scope. | Record RC3 build, PHP, database, web server, object cache, Imagick, Ghostscript, plugin, theme, and mu-plugin versions. | RC3 runs only in an isolated production-like environment. |
| Capture logs, request data, screenshots, and the first known differing build. | Clone representative content and configuration without exposing customer secrets or live callbacks. | The 7.0.4 security backport and required media workflows both pass. |
| Report core regressions with reproducible steps and move plugin issues to the correct vendor. | Define business-critical journeys and security boundaries before the candidate is installed. | Critical forms, checkout, email, REST, cron, cache, and editor fixtures have retained evidence. |
| Apply only reversible staging workarounds while the candidate is under review. | Run the same fixtures against the current production baseline and RC3 so changed behavior is measurable. | Every failure has severity, owner, reproduction, decision, and retest state. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
gate,fixture,production,rc3,owner,status
media,author-jpeg,pass,pass,editorial,green
forms,consent-denied,pass,pass,tracking,green
checkout,guest-card,pass,review,commerce,hold
cron,scheduled-post,pass,pass,platform,green
Production verification checklist
- RC3 runs only in an isolated production-like environment.
- The 7.0.4 security backport and required media workflows both pass.
- Critical forms, checkout, email, REST, cron, cache, and editor fixtures have retained evidence.
- Every failure has severity, owner, reproduction, decision, and retest state.
Why this usually happens
- A security backport can touch code paths that ordinary homepage smoke tests never exercise.
- Release-candidate environments drift from production when package, cache, data volume, and callback behavior are simplified.
- Teams test plugins individually but miss failures created by the full theme, plugin, cache, and hosting combination.
Field notes
- Do not connect an RC environment to live payment, advertising, email, or customer systems without explicit isolation.
- Save the RC2 comparison so RC3 failures are attributed to the correct candidate delta.
- Retest the final release even when RC3 passes because the release package and environment are different artifacts.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not treat a green screen, successful request, or quiet log as proof that the customer outcome is correct.
- Do not leave debug logs, broad credentials, test orders, temporary roles, or firewall exceptions active after verification.
- Do not close the work without recording versions, fixture IDs, UTC timestamps, owner, result, and rollback point.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, cache, data shape, roles, integrations, and server packages. Finish with one controlled production fixture when the result depends on real email routing, edge cache, crawler access, payment callbacks, or advertising diagnostics.
What evidence should be retained?
Keep the smallest useful evidence set: exact versions, stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, decision, and final verification. Redact customer data, secrets, order keys, and full click identifiers.
When should the change be rolled back?
Roll back when a revenue, privacy, security, publishing, or lead path fails and the cause cannot be isolated inside the approved maintenance window. Preserve the failed fixture before rollback so the next attempt starts with facts.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
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.
Helpful references