The WordPress 7.1 Field Guide covers more than 310 Core Trac tickets, almost 600 Gutenberg enhancements, more than 630 Gutenberg bug fixes, and 20 new hooks. Reading the list is useful, but release readiness comes from mapping each relevant change to code owners, fixtures, and production evidence.
Use this for plugin vendors, theme teams, agencies, hosts, QA leads, and site owners with custom blocks, media workflows, admin extensions, REST integrations, privacy tools, or editor customizations.
Quick answer
Search the field guide by the APIs, screens, hooks, blocks, and workflows your code owns. Put every relevant change into an impact register with owner, affected component, test fixture, risk, result, and follow-up. Ignore unrelated sections deliberately, but record why they are out of scope.
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 |
|---|
| Theme | theme.json, patterns, custom CSS, navigation, icons, responsive states | Editor and frontend output match at representative widths and states |
| Plugin | hooks, capabilities, REST, admin screens, DataViews, custom blocks | No errors, permission drift, missing controls, or stale assumptions |
| Media | large photos, transparency, rotation, multiple sizes, failed upload | Dimensions, quality, metadata, and errors remain correct |
| Operations | cron, email, updates, privacy export, multisite, rollback | Background and recovery workflows pass with production-shaped data |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Search the Field Guide by ownership | Map editor and theme ownership across global styles, SVG icons, block support, DataViews, DataForm, view configuration, and iframe behavior. | Every custom plugin, theme, block, and integration has a named test owner. |
| Build the impact register | Review media upload code for client-side processing, REST dimension validation, quality changes, generated sizes, and metadata assumptions. | Relevant Core and Gutenberg changes are linked to concrete fixtures. |
| Assign representative fixtures | Check admin extensions against persistent admin navigation, jQuery UI 1.14.2, accessible tooltips, and changed screen behavior. | Deferred features are not described as WordPress 7.1 capabilities. |
| Run and preserve evidence | Search custom code for new or changed hooks, deprecated behavior, direct DOM selectors, REST fields, and capability checks. | Failures include reproducible steps, logs, affected versions, and rollback guidance. |
What to check first
- Map editor and theme ownership across global styles, SVG icons, block support, DataViews, DataForm, view configuration, and iframe behavior.
- Review media upload code for client-side processing, REST dimension validation, quality changes, generated sizes, and metadata assumptions.
- Check admin extensions against persistent admin navigation, jQuery UI 1.14.2, accessible tooltips, and changed screen behavior.
- Search custom code for new or changed hooks, deprecated behavior, direct DOM selectors, REST fields, and capability checks.
- Separate shipped WordPress 7.1 changes from items that did not make the release, including React 19 and real-time collaboration.
Field notes
- Link every inventory row to the exact Field Guide section or developer note that created it.
- Use one canonical test owner per behavior so two pages or teams do not publish conflicting guidance.
- Keep deferred features out of release notes and customer promises.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
impact_register:
source: WordPress 7.1 Field Guide
area: client-side media processing
owner: media-plugin-team
fixture: 18MB rotated JPEG with transparency alternative
expected: dimensions and generated sizes preserved
result: pending
release_gate: required
Why this usually happens
- Large releases distribute changes across Core, Gutenberg, developer notes, and component-specific documentation.
- A change that is small in Core can affect a plugin that depends on internal markup, timing, or undocumented behavior.
- Teams often test the feature headline while missing accessibility, privacy, media, and admin consequences.
Decision rule
A component is ready only when every relevant Field Guide row is passed, explicitly out of scope with a reason, or accepted as a documented risk by its owner.
Production verification checklist
- Every custom plugin, theme, block, and integration has a named test owner.
- Relevant Core and Gutenberg changes are linked to concrete fixtures.
- Deferred features are not described as WordPress 7.1 capabilities.
- Failures include reproducible steps, logs, affected versions, and rollback guidance.
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.
- Search the Field Guide by ownership
- Build the impact register
- Assign representative fixtures
- Run and preserve evidence
- Close or escalate every row
Mistakes to avoid
- Do not turn the Field Guide into an unowned reading list.
- Do not test only the most visible editor features.
- Do not assume an unchanged public API means unchanged integration behavior.
- Do not include features that missed WordPress 7.1.
Questions teams ask during testing
How large is WordPress 7.1?
The official Field Guide reports more than 310 Core tickets, with more than 100 enhancements and features and more than 180 bug fixes.
How many new hooks are documented?
The Field Guide lists 20 new hooks, including 19 filters and one action.
Did React 19 ship in WordPress 7.1?
No. The Field Guide identifies React 19 and real-time collaboration as work that did not make this release.
What to tell the client or owner
Share the Field Guide section, affected repository and version, owner, fixture, expected result, actual result, screenshots, logs, and release decision.
When HandL WP should help
HandL WP can translate the WordPress 7.1 Field Guide into a scoped compatibility register, fixtures, evidence, and an owner-based production decision.
If this is active on a production site, review WordPress 7.1 plugin and theme impact.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Assign durable ownership to custom icon collections
Add custom icon namespaces to the extension inventory with the WordPress 7.1 icon collection collision test for prefixed slugs, translated labels, activation order, pattern references, multisite, and safe removal.
Add focused Settings API and sortable tests
Two WordPress 7.1 field-guide changes deserve concrete plugin checks. Use the Settings API duplicate section ID audit for headings, labels, fragments, and selectors. Use the jQuery UI 1.14.2 sortable regression test for pointer input, keyboard alternatives, persistence failures, and reload parity.
Test persistent toolbar behavior in real editor transitions
The WordPress 7.1 persistent admin bar compatibility test checks custom nodes, permissions, fixed offsets, distraction-free mode, mobile layouts, focus, stale nonces, and duplicate JavaScript listeners across Post and Site Editor navigation.
Helpful references