WordPress 7.1 & theme.json v3 Compatibility

WordPress 7.1 moves the block editor canvas to a full iframe for every post/page editing session, upgrades theme.json to the v3 schema, and standardizes a viewport scale for editor previews. WP Rig 3.5 is verified compatible — this post explains what changed, what WP Rig does about it, and what to do in your own blocks.

theme.json v3

WP Rig’s generated theme.json targets the v3 / 7.1 schema. What that adds:

• settings.viewport — mobile 480px / tablet 782px. Core now knows your breakpoints, and the editor’s preview widths agree with your frontend media queries.
• settings.blockVisibility — explicit opt-in (allowEditing: true) for core’s block-visibility controls.
• Token-derived layout sizes — content/wide widths come from your design tokens, not literals.
• Pseudo-state styling — link hover/focus/active/visited states live in theme.json styles.elements.link (conflict-audited against buttons, forms, and navigation), so the editor and frontend render identical interactive states. _links.css keeps only focus/outline affordances.

theme.json itself is generated — scripts/tasks/tokens.js (pure buildThemeJson()) is the sole writer, fed by config/tokens.json, config/theme.custom.json, and any baked overlay. See Design Tokens v2 for the merge order.

One breakpoint scale everywhere

All seven @custom-media aliases in your CSS derive from settings.viewport — so frontend media queries, the JS breakpoint (read as a runtime custom property), the editor preview, and core’s block-visibility classes (wp-block-hidden-*) all share one scale. The hamburger hides at 481px; the nav collapses at 782px; the editor preview agrees at both. Guidance: use block visibility for content blocks, and keep Navigation/theme parts theme-managed to avoid double-toggling.

The full-iframe editor

With 7.1, editor styles and scripts run inside an isolated iframe document. WP Rig passes the audit on all three fronts:

• Styles: theme styles enqueue via add_editor_style(), which WordPress adapts into the iframe automatically; block editorStyle handles are injected correctly; no .wp-admin/.editor-styles-wrapper dependencies exist in source styles.
• JavaScript: source files make no global window/document assumptions that would miss iframe-resident elements.
• apiVersion: 3: block scaffolding (block:new), fallback templates, and the demo blocks all declare it — the official signal of iframe compatibility.

One known console notice (global-styles-css-custom-properties-inline-css … added to the iframe incorrectly) is a confirmed WP core quirk: the handle is core-generated and disabling theme editor styles does not remove it. Styles apply correctly; WP Rig is monitoring core.

Writing iframe-safe blocks

For complex interactive blocks, target the iframe’s isolated document through the element’s owner document — never the page globals:

import { useRefEffect } from '@wordpress/compose';
const ref = useRefEffect( ( element ) => {
	const ownerDocument = element.ownerDocument; // the iframe document
	const ownerWindow = ownerDocument.defaultView; // the iframe window
}, [] );

import { useRefEffect } from '@wordpress/compose';

const ref = useRefEffect( ( element ) => {
	const ownerDocument = element.ownerDocument; // the iframe document
	const ownerWindow = ownerDocument.defaultView; // the iframe window
}, [] );

Building Custom Blocks scaffolds apiVersion: 3 blocks that already follow this rule.

Related reading

Design Tokens v2 (what feeds theme.json), Modern CSS with Lightning CSS (the viewport-driven media queries), and Building Custom Blocks.