WordPress 7.1 Beta 3 arrived after Beta 2 carried the WordPress 7.0.2 security fixes. A normal visual smoke test is not enough for that transition. Teams need to retest authentication, authorization, REST requests, uploads, nonces, role boundaries, and security-plugin integrations on a staging copy that contains representative configuration but no unnecessary personal data.
Use this for plugin developers, theme developers, agencies, managed hosts, and site owners preparing for WordPress 7.1. Do not install Beta 3 on a production or mission-critical site. The goal is to find a reproducible regression and produce a useful report, not to prove that every screen opens.
Quick answer
Clone a representative site to isolated staging, record the exact Beta 2 baseline, update only WordPress core to 7.1 Beta 3, and replay the same security-sensitive tests. Compare status codes, capability checks, nonces, database writes, log entries, and user-visible results. Treat any newly permitted action, blocked legitimate action, fatal error, or missing audit event as a regression candidate until isolated.
What to check first
- Capture core, PHP, database, web server, active theme, must-use plugin, security plugin, cache, and authentication integration versions before changing the baseline.
- Test login, logout, password reset, application passwords, session invalidation, administrator and editor boundaries, and one custom role with the same accounts on both builds.
- Replay representative REST reads and writes with valid, missing, expired, and wrong-user nonces, then record the route, method, response status, response body class, and database effect.
- Upload allowed and blocked file types, rotated EXIF images, a long animated GIF, and a HEIC image because Beta 3 includes media handling fixes that can intersect with validation and resource limits.
- Compare WordPress debug logs, PHP logs, WAF events, security-plugin events, outbound requests, cron, and unexpected account or option changes for the same test IDs.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze and record the Beta 2 baseline | Capture core, PHP, database, web server, active theme, must-use plugin, security plugin, cache, and authentication integration versions before changing the baseline. | Every test row has a Beta 2 result and a Beta 3 result from the same environment. |
| Update core only on isolated staging | Test login, logout, password reset, application passwords, session invalidation, administrator and editor boundaries, and one custom role with the same accounts on both builds. | Unauthorized requests remain blocked without creating database, file, or outbound side effects. |
| Replay identical role and request tests | Replay representative REST reads and writes with valid, missing, expired, and wrong-user nonces, then record the route, method, response status, response body class, and database effect. | Authorized requests still work for the intended role and produce the expected audit trail. |
| Reduce any difference to a minimal reproduction | Upload allowed and blocked file types, rotated EXIF images, a long animated GIF, and a HEIC image because Beta 3 includes media handling fixes that can intersect with validation and resource limits. | Any candidate regression reproduces after cache reset and with unrelated plugins disabled. |
Why this usually happens
- A security fix can change request validation or authorization in code paths used by plugins.
- Cached nonces, object cache entries, and persistent browser sessions can make two builds look different for the wrong reason.
- REST clients and custom roles often depend on behavior that is not covered by a homepage smoke test.
- Image processing fixes exercise file validation, temporary storage, memory limits, and metadata handling together.
- Security plugins may classify a new core request pattern as suspicious even when WordPress handles it correctly.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
test_id: WP71B3-SEC-014
baseline: 7.1-beta2
candidate: 7.1-beta3
actor_role: editor
route: /wp-json/wp/v2/media
method: POST
nonce_case: wrong_user
baseline_status: 403
candidate_status: 403
database_write: none
log_correlation_id: wp71b3-sec-014
result: pass
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Freeze and record the Beta 2 baseline
- Update core only on isolated staging
- Replay identical role and request tests
- Reduce any difference to a minimal reproduction
- Retest with current nightly before reporting
Decision rule
Pass the delta only when Beta 3 preserves the expected authorization boundary and produces no unexplained write, disclosure, fatal error, or security-tool block. A visual difference is not automatically a security regression, and a 200 response is not automatically correct if the response exposes or changes data the actor should not control.
What to tell the client or owner
Report the affected build, minimal plugin and theme set, actor role, exact request, expected and observed results, logs, and reproduction steps. Remove credentials, cookies, nonces, personal data, and infrastructure secrets from shared evidence.
Production verification checklist
- Every test row has a Beta 2 result and a Beta 3 result from the same environment.
- Unauthorized requests remain blocked without creating database, file, or outbound side effects.
- Authorized requests still work for the intended role and produce the expected audit trail.
- Any candidate regression reproduces after cache reset and with unrelated plugins disabled.
Mistakes to avoid
- Do not run Beta 3 on production to get realistic traffic.
- Do not compare two sites with different plugin, cache, PHP, or database states.
- Do not share live cookies, nonces, application passwords, or customer records in a ticket.
- Do not report a WAF block as a core bug until the WordPress response is tested without that policy layer.
Questions teams ask during testing
Should WordPress 7.1 Beta 3 replace the production 7.0.2 update?
No. Production sites should remain on supported stable and patched releases. Beta 3 is for isolated testing before WordPress 7.1 ships.
What is the most valuable regression to report?
A small, repeatable case that shows the same request and actor producing a security-relevant difference between builds, with logs and expected behavior clearly stated.
When HandL WP should help
Bring in HandL WP when the issue affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, review a WordPress 7.1 regression.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Focused WordPress 7.1 Beta 3 regression tests
Continue the Beta 3 delta with the Apply globally style review test and the long animated GIF timeout test. Both guides preserve a comparable baseline, isolate one changed behavior, and include rollback evidence.
Focused WordPress 7.1 custom-block and media tests
Test selective styling in a real extension with the Apply globally custom-block support test. For long animated media on an offload stack, use the animated GIF object-storage timeout test to separate image processing, transfer, commit, retry, and cleanup.
Helpful references