The WordPress 7.1 Field Guide is written for contributors and developers across many components. A site owner still needs to convert those changes into a production inventory covering the editor, media, themes, plugins, APIs, identities, accessibility, privacy, cache behavior, forms, checkout, and rollback ownership.
Use this as the owner page for agencies and site teams planning or reviewing a WordPress 7.1 production upgrade.
Quick answer
Start with exact versions and revenue or lead journeys, then map every relevant Field Guide section to an installed component and named owner. Build a canary that covers editor saves, media transformations, responsive styles, navigation, users, forms, checkout, REST, cron, cache MISS and HIT behavior, accessibility, and privacy. Hold unrelated changes. Promote only when hard gates pass and the observation window has a rollback owner.
What to check first
- Inventory WordPress, PHP, database, theme, blocks, plugins, mu-plugins, REST clients, media processors, cache layers, and business journeys.
- Map Field Guide sections to the installed components and mark each one affected, not affected, unknown, or tested.
- Create role-specific fixtures for editor, media, forms, checkout, accounts, APIs, cron, email, and accessibility.
- Separate release blockers from observations and write a measurable budget for fatal errors, latency, queue age, and conversion failures.
- Publish the owner matrix, rollback point, observation window, and linked child tests before broad rollout.
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 |
|---|
| Editor | Save, preview, responsive styles | No content or CSS regression |
| Media | Upload, crop, transform, metadata | Derivative set reconciles |
| Business | Form, checkout, account, email | Stable IDs and outcomes |
| Platform | REST, cron, cache, PHP logs | Inside written budgets |
Decision rule
Approve WordPress 7.1 only when every installed affected component has an owner and result, every hard journey passes, and unresolved observations have a written budget and rollback trigger.
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.
- Translate Field Guide sections into an installed-component inventory.
- Assign every affected journey a fixture, gate, and owner.
- Run the smallest representative canary with unrelated updates held.
- Close blockers and document accepted observations separately.
- Promote gradually with current rollback and monitoring evidence.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Translate Field Guide sections into an installed-component inventory. | Inventory WordPress, PHP, database, theme, blocks, plugins, mu-plugins, REST clients, media processors, cache layers, and business journeys. | Every relevant Field Guide area maps to an installed component or explicit not-applicable result. |
| Assign every affected journey a fixture, gate, and owner. | Map Field Guide sections to the installed components and mark each one affected, not affected, unknown, or tested. | Editor, media, forms, checkout, users, APIs, cron, and cache fixtures pass. |
| Run the smallest representative canary with unrelated updates held. | Create role-specific fixtures for editor, media, forms, checkout, accounts, APIs, cron, email, and accessibility. | Fatal, latency, queue, and conversion measures stay inside budget. |
| Close blockers and document accepted observations separately. | Separate release blockers from observations and write a measurable budget for fatal errors, latency, queue age, and conversion failures. | The rollout, hold queue, observation window, and rollback owner are recorded. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
area,component,journey,owner,fixture,gate,result
editor,iframe,save+preview,content,E-71,hard,pass
media,client-processing,upload+crop,design,M-71,hard,pass
api,abilities,role+schema,engineering,A-71,hard,review
cache,speculation,miss+hit,platform,C-71,watch,pass
Production verification checklist
- Every relevant Field Guide area maps to an installed component or explicit not-applicable result.
- Editor, media, forms, checkout, users, APIs, cron, and cache fixtures pass.
- Fatal, latency, queue, and conversion measures stay inside budget.
- The rollout, hold queue, observation window, and rollback owner are recorded.
Why this usually happens
- Developer notes are grouped by component instead of business journey.
- A feature can be irrelevant on one site and critical on another.
- Plugin and theme compatibility evidence may lag the core release.
- A broad checklist without owners becomes a list no one can close.
Field notes
- Link each risk to one reproducible child test.
- Use production-like roles and data volume on staging.
- Keep security-critical updates on their own urgency track.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful screen as proof that background jobs, APIs, caches, roles, reports, and downstream records agree.
- Deleting logs or identifiers before the failure boundary, business impact, rollback point, and accountable owner are known.
- Testing only an administrator session instead of the devices, roles, networks, data states, and failure paths real users have.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, current cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window remains open.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a real customer, expose personal data, or change inventory. Perform destructive repairs, upgrades, cache changes, and schema work on staging first.
What evidence should the report keep?
Keep exact versions, UTC timestamps, stable synthetic IDs, expected and actual results, the decision owner, rollback point, and final verification. Redact customer data, credentials, tokens, addresses, and private infrastructure details.
When is the task complete?
Complete the task when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context.
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, plan a WordPress 7.1 upgrade.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Plan the server lifecycle beyond minimum compatibility
Add the WordPress 7.1 server compatibility and PHP 8.2 EOL plan to inventory web, cron, CLI, database, extensions, canary tests, and rollback before the support deadline.
Keep the WordPress 7.1 owner current with measured signals
Use the WordPress 7.1 query owner refresh cadence to combine official release changes, vendor hotfixes, support declarations, Search Console demand, internal links, and scoped snippet tests.
Test permissions before teams share visual revision URLs
For Gutenberg 23.8 collaboration, run the revision share URL permission test across roles, expired sessions, private posts, autosaves, changed permissions, caches, and link retention.
Helpful references