Context
As part of the WordPress 7.0 compatibility effort (#481), we identified that all 23 Nova Blocks blocks currently use apiVersion: 2. WordPress 7.0 introduces the iframed block editor, and apiVersion: 3 is the official way to declare full iframe compatibility.
Current state
- apiVersion 2 still works in WP 7.0 — WordPress provides a compatibility shim that wraps v2 blocks
- All critical cross-frame DOM issues have already been fixed in wave 2 of the WP7 plan (useScrollContainer, navigation block, etc.)
- The compatibility shim adds minor overhead but is not breaking
What needs to happen
- Audit all 23 blocks for any remaining direct
document/window access in their edit components
- Fix any found issues (use
ownerDocument / defaultView patterns established in wave 2)
- Bump
apiVersion from 2 to 3 in each block's block.json
- Test each block in the iframed editor to verify no regressions
Why it was deferred
- apiVersion 2 compatibility mode works fine, so this is not blocking
- Touching 23 blocks at once carries cascading risk
- Better done as a focused effort with thorough per-block testing
Reference
- Deferral rationale:
plans/2026-03-02-nova-blocks-wave5-apiversion3.md (in anima repo)
- Parent WP7 plan:
plans/2026-03-02-wordpress-7-compatibility.md (in anima repo)
- Related: #481
Context
As part of the WordPress 7.0 compatibility effort (#481), we identified that all 23 Nova Blocks blocks currently use
apiVersion: 2. WordPress 7.0 introduces the iframed block editor, andapiVersion: 3is the official way to declare full iframe compatibility.Current state
What needs to happen
document/windowaccess in theireditcomponentsownerDocument/defaultViewpatterns established in wave 2)apiVersionfrom2to3in each block'sblock.jsonWhy it was deferred
Reference
plans/2026-03-02-nova-blocks-wave5-apiversion3.md(in anima repo)plans/2026-03-02-wordpress-7-compatibility.md(in anima repo)