Before WordPress 7.1, the presence of an older block could make the Post Editor fall back to a non-iframed canvas. Teams could therefore miss iframe defects whenever a fixture happened to include a Block API v2 block or certain legacy integrations. WordPress 7.1 removes that accidental fallback, so mixed posts need a deliberate regression test.
Use this for mature WordPress sites with classic meta boxes, custom post types, older registered blocks, Advanced Custom Fields integrations, editorial workflow panels, legacy shortcodes, or plugins that have not completed a Block API migration.
Quick answer
Inventory block API versions and meta boxes, then build four fixtures: modern blocks only, v2 block only, modern plus v2 blocks, and the same mixed post with every production meta box active. Compare editor behavior, saved metadata, REST updates, autosave, revisions, preview, and published output on WordPress 7.0.2 and 7.1.
What to check first
- Export registered block names and API versions, including blocks bundled by themes, mu-plugins, private plugins, and page builder extensions.
- List every meta box with screen, context, priority, capability, nonce, save callback, REST exposure, and whether it uses JavaScript to inspect editor content.
- Create modern-only, v2-only, mixed-block, and mixed-block-plus-meta-box fixtures using deterministic content and values.
- Test autosave, manual save, preview, publish, revision restore, post lock, browser refresh, block recovery, and direct REST updates for each fixture.
- Migrate owned blocks toward the current Block API contract while keeping a versioned fallback for the oldest WordPress release the plugin supports.
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 |
|---|
| Inventory versions and meta boxes | Export registered block names and API versions, including blocks bundled by themes, mu-plugins, private plugins, and page builder extensions. | Every fixture opens with the expected iframe and no unsupported fallback assumption. |
| Build four mixed fixtures | List every meta box with screen, context, priority, capability, nonce, save callback, REST exposure, and whether it uses JavaScript to inspect editor content. | Block content, post fields, and meta box values survive autosave, manual save, preview, publish, revision restore, and direct REST updates. |
| Compare 7.0.2 and 7.1 | Create modern-only, v2-only, mixed-block, and mixed-block-plus-meta-box fixtures using deterministic content and values. | Supported roles can use approved controls, while direct requests still enforce capabilities and nonces. |
| Correct asset and save contracts | Test autosave, manual save, preview, publish, revision restore, post lock, browser refresh, block recovery, and direct REST updates for each fixture. | Owned blocks either meet the current Block API contract or have a documented compatibility path and test coverage. |
Why this usually happens
- A test post with an older block previously removed the iframe and hid code that targeted the wrong document.
- A meta box save callback can overwrite REST-saved values when nonce or autosave conditions are not handled consistently.
- Legacy CSS may reach a non-iframed canvas through admin selectors but never enter the WordPress 7.1 iframe.
- An old block deprecation path can serialize different markup after a WordPress or Gutenberg upgrade.
Field notes
- Store fixture values that reveal stale saves, such as unique tokens for autosave, manual save, REST update, and revision restore.
- Capture the iframe state in WordPress 7.0.2 for each fixture. The point is to prove which failures were previously hidden.
- Do not use customer post content in the regression pack. Use synthetic text, images, IDs, and metadata.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp block list --format=json | jq '[.[] | {name, version}]'
# Exercise the same post through REST after an editor save.
wp post meta get 1042 _fixture_token
wp post meta update 1042 _fixture_token rest-20260803
wp post meta get 1042 _fixture_token
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.
- Inventory versions and meta boxes
- Build four mixed fixtures
- Compare 7.0.2 and 7.1
- Correct asset and save contracts
- Migrate owned v2 blocks with fallbacks
Decision rule
Do not approve the upgrade when fixture content or metadata changes unexpectedly, a supported role loses access, a block enters recovery, or an owned v2 block depends on the old non-iframed fallback. Record third-party failures with a vendor version and containment plan.
What to tell the client or owner
Provide the block name and API version, meta box ID, post type, role, fixture token, editor action, stored before and after values, REST response, WordPress builds, and recovery or console evidence.
Production verification checklist
- Every fixture opens with the expected iframe and no unsupported fallback assumption.
- Block content, post fields, and meta box values survive autosave, manual save, preview, publish, revision restore, and direct REST updates.
- Supported roles can use approved controls, while direct requests still enforce capabilities and nonces.
- Owned blocks either meet the current Block API contract or have a documented compatibility path and test coverage.
Mistakes to avoid
- Do not remove a legacy block from the test just because it is scheduled for later migration.
- Do not infer save correctness from the success notice without rereading stored values.
- Do not disable every meta box in production to make the editor appear healthy.
- Do not update block markup without testing existing saved posts and deprecations.
Questions teams ask during testing
Will a Block API v2 block stop the iframe in WordPress 7.1?
No. The August 3 dev note says the Post Editor will be iframed regardless of registered or present block API versions.
Do classic meta boxes disappear?
Not automatically. Test their rendering, JavaScript, capability checks, nonces, and save lifecycle in your actual post type.
Can we migrate every block in one release?
Only with adequate fixtures and rollback coverage. A staged migration is safer for mature sites with many saved posts.
When HandL WP should help
HandL WP can inventory legacy blocks and meta boxes, build mixed-content fixtures, correct iframe and save regressions, and run an upgrade gate against real editorial workflows.
If this is active on a production site, test legacy editor integrations for WordPress 7.1.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references