WordPress 7.1 is scheduled for August 19, 2026, and the RC2 milestone is scheduled for August 12. A plugin page that says compatible or a vendor ticket that says supported does not prove a site's checkout, forms, editor, cache, cron, tracking, or custom code works. Teams need one matrix that connects each dependency to its installed version, vendor statement, actual fixture, result, owner, and rollback choice.
Use this during the final WordPress 7.1 release window for business sites with revenue, lead, membership, publishing, multilingual, or custom integration workflows.
Quick answer
Inventory production plugin, theme, must-use plugin, drop-in, and custom-code versions. Record the latest vendor compatibility statement without treating it as a pass. Run the site's critical fixtures on a staging copy against the current 7.1 release candidate, then mark each dependency tested, blocked, waived, or not applicable with an owner and rollback point.
What to check first
- Export WordPress, PHP, database, theme, plugin, must-use plugin, drop-in, and custom package versions from production.
- Link each critical dependency to its current vendor changelog, tested-up-to claim, issue, or support response.
- Map plugins to business workflows such as checkout, forms, email, cron, search, login, editor, cache, and tracking.
- Run one controlled fixture per critical workflow on the same release-candidate build and production-like stack.
- Assign an owner, blocker, workaround, rollback version, and retest date for every row that is not a clean pass.
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 |
|---|
| Checkout stack | Cart, coupon, tax, payment, email, refund | One order completes and reverses with correct records |
| Lead stack | Primary form, spam control, CRM, email, attribution | One lead keeps IDs and reaches each destination once |
| Publishing stack | Editor, custom blocks, preview, revision, scheduled post | Content can be created, reviewed, and published |
| Operations stack | Cron, cache, backup, monitoring, CLI | Scheduled and recovery workflows remain observable |
Decision rule
Approve WordPress 7.1 only when every critical workflow has a passing site-specific fixture, any vendor uncertainty has an owned mitigation, and the team can restore the previous build and data state inside the maintenance window.
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.
- Create the exact production dependency inventory.
- Collect current vendor statements and known issues.
- Run critical workflow fixtures against the current RC build.
- Resolve or explicitly waive blockers with named owners.
- Rehearse backup, rollback, cache purge, and post-update verification.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Create the exact production dependency inventory. | Export WordPress, PHP, database, theme, plugin, must-use plugin, drop-in, and custom package versions from production. | The matrix names the exact WordPress RC and dependency versions tested. |
| Collect current vendor statements and known issues. | Link each critical dependency to its current vendor changelog, tested-up-to claim, issue, or support response. | Every revenue, lead, publishing, login, and scheduled workflow has concrete evidence. |
| Run critical workflow fixtures against the current RC build. | Map plugins to business workflows such as checkout, forms, email, cron, search, login, editor, cache, and tracking. | No critical row relies only on a vendor compatibility label. |
| Resolve or explicitly waive blockers with named owners. | Run one controlled fixture per critical workflow on the same release-candidate build and production-like stack. | Rollback artifacts, commands, owners, and communication steps have been rehearsed. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
component,version,vendor_claim,workflow,fixture,result,owner,rollback
WooCommerce,11.0.1,tested,checkout,order-rc2,pass,commerce,11.0.1
Custom blocks,2.8.0,unknown,publishing,page-42,review,content,2.7.4
SMTP plugin,4.6.2,supported,lead email,form-9,pass,marketing,4.6.2
Production verification checklist
- The matrix names the exact WordPress RC and dependency versions tested.
- Every revenue, lead, publishing, login, and scheduled workflow has concrete evidence.
- No critical row relies only on a vendor compatibility label.
- Rollback artifacts, commands, owners, and communication steps have been rehearsed.
Why this usually happens
- Tested-up-to metadata can lag behind actual compatibility or cover only a plugin's basic screen.
- A vendor cannot test the exact combination of custom code, cache, hosting, extensions, and data shape on one site.
- A broad smoke test often misses asynchronous work that fails only after checkout, submit, publish, or cron.
Field notes
- Record the exact RC build because results from RC1 and RC2 are not interchangeable.
- Freeze unrelated plugin and theme updates while comparing the release candidate.
- Keep the vendor claim, internal test, and production decision as separate columns.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not use a successful status or screen message as the only proof. Verify the business outcome and the underlying record.
- Do not leave debug logging, broad credentials, test orders, or temporary exceptions active after the review.
- Do not close the incident without recording the fixture, 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, and integrations. Finish with one controlled production fixture when the result depends on real routing, provider, or edge behavior.
What evidence should be retained?
Keep the smallest useful set: stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, version inventory, and the final verification.
When should the change be rolled back?
Roll back when a revenue, privacy, security, or publishing path fails and the cause cannot be isolated inside the approved maintenance window.
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, test a WordPress 7.1 release.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references