WordPress.org says the 7.1 beta line was affected by both vulnerabilities fixed in WordPress 7.0.2 and that Beta 2 contains the fixes. Teams that tested Beta 1 need a clean Beta 2 run because a security patch can change request handling while the wider 7.1 compatibility surface is still moving.
Use this for plugin and theme maintainers, agencies, QA teams, and site owners running WordPress 7.1 pre-release builds on disposable staging environments.
Quick answer
Install Beta 2 on a fresh or restorable staging copy, verify the core build, then rerun REST, editor, media, login, cron, and plugin smoke tests. Keep security assertions separate from compatibility results, and never expose a beta environment with production credentials or customer data.
What to check first
- Clone a controlled test case or rebuild staging from a known snapshot, then remove production secrets, payment keys, customer email addresses, and public indexing.
- Record the Beta 1 baseline and install Beta 2 through the supported beta channel so the exact build and update path are reproducible.
- Retest authenticated and unauthenticated REST routes, batch requests, nonce failures, application passwords, role boundaries, and security-plugin rules.
- Run plugin activation, theme rendering, block editor, persistent toolbar, media processing, forms, checkout, cron, and WP-CLI smoke tests with logs enabled only for the test window.
- Restore the snapshot or apply the documented rollback, then prove the environment can return to the prior state without stale object or CDN cache.
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 |
|---|
| Rebuild controlled staging | Clone a controlled test case or rebuild staging from a known snapshot, then remove production secrets, payment keys, customer email addresses, and public indexing. | The exact Beta 2 build and test inventory are recorded. |
| Install the exact beta | Record the Beta 1 baseline and install Beta 2 through the supported beta channel so the exact build and update path are reproducible. | REST and role-boundary tests have expected status codes and logs. |
| Retest security boundaries | Retest authenticated and unauthenticated REST routes, batch requests, nonce failures, application passwords, role boundaries, and security-plugin rules. | Critical plugins, themes, editor, media, forms, checkout, and cron have named results. |
| Run business smoke tests | Run plugin activation, theme rendering, block editor, persistent toolbar, media processing, forms, checkout, cron, and WP-CLI smoke tests with logs enabled only for the test window. | Rollback restores the prior build and clears test cache without data loss. |
Why this usually happens
- A test that passed on Beta 1 does not prove Beta 2 behavior after a security-sensitive code change.
- Security plugins and WAF rules can produce false failures that look like core REST regressions.
- Persistent object cache can carry data across test rounds and hide a clean-build difference.
- A beta site copied from production can send real mail or payment calls unless outbound integrations are disabled.
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 plugin list --fields=name,status,version,update
wp theme list --fields=name,status,version,update
wp option get home
wp cron event run --due-now
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.test/wp-json/
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.
- Rebuild controlled staging
- Install the exact beta
- Retest security boundaries
- Run business smoke tests
- Prove rollback
Decision rule
File a regression only after reproducing it on Beta 2 with a minimal plugin set and clear request evidence. Keep production on a supported stable branch until the final 7.1 release and a normal rollout decision.
What to tell the client or owner
Share the staging isolation controls, Beta 1 baseline, Beta 2 build, plugin and theme inventory, REST cases, browser and PHP logs, screenshots, minimal reproduction, rollback result, and owner for each failure.
Production verification checklist
- The exact Beta 2 build and test inventory are recorded.
- REST and role-boundary tests have expected status codes and logs.
- Critical plugins, themes, editor, media, forms, checkout, and cron have named results.
- Rollback restores the prior build and clears test cache without data loss.
Mistakes to avoid
- Do not test a beta on the only copy of a production site.
- Do not report a security-plugin block as a core bug before isolating the layer.
- Do not leave outbound email, payment, webhook, or indexing enabled on the test copy.
- Do not compare Beta 2 to memory when a recorded Beta 1 baseline is available.
Questions teams ask during testing
Should production sites move to WordPress 7.1 Beta 2 for the security fix?
No. Production sites should use the patched stable release for their maintained branch. Beta 2 is for controlled testing of the upcoming 7.1 release.
What evidence belongs in a compatibility report?
Include the exact core build, plugin and theme versions, minimal reproduction steps, request or browser output, relevant logs, expected result, actual result, and whether the issue remains with other plugins disabled.
When HandL WP should help
HandL WP can help agencies build a repeatable WordPress 7.1 compatibility lab, isolate plugin conflicts, and turn unclear beta failures into useful evidence before production rollout.
If this is active on a production site, retest WordPress 7.1 Beta 2 safely.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references