WordPress 7.1 Developer Readiness Guide

Last verified: July 26, 2026
Release tested: WordPress 7.1 Beta 3
Scheduled stable release: August 19, 2026
Next major checkpoint: Release Candidate 1 and the WordPress 7.1 Field Guide, scheduled for August 5, 2026

WordPress 7.1 is not a release where plugin and theme authors can stop after updating a Tested up to header.

The release changes where image processing happens, removes the post editor’s non-iframe compatibility path, changes several @wordpress/components behaviors, enables Media Library infinite scrolling by default, and introduces new styling data that block-aware products may need to understand.

At the time of publication, WordPress 7.1 Beta 3 is the current pre-release build. Beta 4 is scheduled for July 29, Release Candidate 1 for August 5, Release Candidate 2 for August 12, and the final release for August 19. Pre-release versions are intended only for local, staging, and test environments—not production websites. (Make WordPress)

This guide focuses on compatibility risks rather than providing another feature roundup.

WordPress 7.1 compatibility risk matrix

Area	Risk	Products most affected	Required action
Client-side media processing	High	Media, CDN, optimization, watermarking, DAM, and upload plugins	Test both browser and server processing paths
Permanently iframed post editor	High	Custom blocks, editor extensions, page builders, DOM-dependent libraries	Remove global document assumptions and migrate blocks to API version 3
Editor component changes	High	Plugins with React-based admin or editor interfaces	Remove obsolete props, components, and utilities
Responsive and interactive styles	Medium	Block libraries, theme frameworks, style engines, content parsers	Verify serialization, CSS output, and custom controls
Persistent admin toolbar	Medium	Admin-bar extensions and editor UI plugins	Test Post and Site Editor layouts
Media Library infinite scrolling	Medium	Media modal, attachment filtering, selection, and bulk-action extensions	Test automatic loading and user opt-out behavior
Editable blocks inside Custom HTML	Medium	Content generators, AI tools, importers, exporters, and block parsers	Stop assuming core/html contains only inert markup
New icon and design APIs	Low	Themes and block libraries	Adopt progressively with backward-compatible guards

---

1. Establish a repeatable WordPress 7.1 test environment

Do not upgrade a development installation that has accumulated years of unrelated plugins, content, and configuration and call that a compatibility test.

Create at least two controlled environments:

1. A clean WordPress installation containing only your product and its required dependencies.
2. A representative staging installation containing realistic content, the customer’s theme, common integrations, and production-like server configuration.

At the time of verification, Beta 3 can be installed with WP-CLI:

wp db export before-wordpress-7.1.sql
wp core update --version=7.1-beta3
wp core update-db
wp core version --extra

Replace 7.1-beta3 with the newest beta or release candidate when repeating the test later in the release cycle. The command above is the installation method documented in the official Beta 3 announcement. (WordPress.org)

Enable useful development logging in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'SCRIPT_DEBUG', true );

During every test run, inspect:

wp-content/debug.log

Also keep the browser console, Network panel, and React error output open. A workflow that appears visually functional may still be generating deprecation warnings, failed REST requests, iframe access errors, or duplicate media-processing calls.

Your continuous integration matrix should eventually cover:

Latest supported stable WordPress
Current WordPress 7.1 beta or release candidate
WordPress trunk, as a non-blocking forward-compatibility job

Do not replace your stable-version tests with 7.1 tests. The objective is to prove that the same release works across the WordPress versions declared in your support policy.

---

2. Audit the new client-side media pipeline

Client-side media processing is the most consequential under-the-hood change in WordPress 7.1 for media-related products.

On supported browsers and devices, WordPress can now perform image decoding, resizing, cropping, format conversion, EXIF rotation, compression, and registered sub-size generation inside the browser using WebAssembly and a Web Worker. Generated files are then uploaded separately through new REST API operations.

Modern Chromium browsers exercise this path. Unsupported browsers, restricted devices, slow connections, and environments that cannot start the worker transparently fall back to the existing server-side process. Firefox and Safari currently use the server fallback for the full WebAssembly pipeline, although Safari can still perform its separate HEIC decoding fallback. (Make WordPress)

Why existing media plugins can break

Your plugin may currently assume that every generated image passes through a PHP image editor.

That assumption is no longer safe.

The following server-specific hooks do not run when the browser generates the image sizes:

wp_image_editors
image_memory_limit
image_make_intermediate_size

Existing configuration filters such as these are still respected by the client-side pipeline:

big_image_size_threshold
image_editor_output_format
image_save_progressive
wp_image_maybe_exif_rotate
wp_editor_set_quality
jpeg_quality

The wp_generate_attachment_metadata filter also continues to run. However, it can run once with a create context during the initial attachment creation and again with an update context after all client-generated sub-sizes have been uploaded and finalized. Watermarking, CDN synchronization, metadata indexing, and similar callbacks must therefore be idempotent and able to handle both passes. (Make WordPress)

Audit every media integration for assumptions such as:

• The PHP image editor always produced the file.
• All intermediate sizes exist during the first metadata call.
• A metadata callback runs exactly once.
• Upload completion means all custom image sizes have finished processing.
• The uploaded source and generated output always use the same format.
• An attachment can have no companion files.
• A remote image can safely be fetched directly from editor-side JavaScript.

Test both processing routes

Use a supported Chrome or Edge version to exercise browser processing. Then repeat the same tests in Firefox or Safari to exercise the server fallback.

You can also explicitly disable client-side processing:

add_filter(
	'wp_client_side_media_processing_enabled',
	'__return_false'
);

Do not ship this filter merely because a compatibility issue exists. Treat it as a diagnostic and emergency compatibility switch while fixing the underlying integration.

Your test collection should include:

File	What to verify
Large JPEG	Big-image scaling, custom sizes, metadata, and quality filters
JPEG with EXIF rotation	Correct orientation in original and generated sizes
Transparent PNG	Alpha-channel preservation
WebP	Upload, sub-sizes, editing, and frontend output
AVIF	Behavior on servers without server-side AVIF support
HEIC/HEIF	Conversion, original companion file, deletion, and metadata
Animated GIF	Animation handling and any generated video companion
UltraHDR JPEG	Gain-map preservation when your product transforms images
Remote image	Server-side import rather than browser-side cross-origin fetching
Batch upload	Concurrency, retries, progress UI, and duplicate processing

WordPress specifically recommends testing custom image sizes, HEIC, AVIF, gain-mapped HDR images, animated GIFs, external resources, and the forced fallback path. (Make WordPress)

Review your Content Security Policy

The WebAssembly worker is created from a blob URL. A strict Content Security Policy must therefore permit blob workers:

Content-Security-Policy: worker-src 'self' blob:;

Merge that directive into the site’s existing policy. Do not replace a complete production CSP with the single directive shown above.

When the directive is missing, WordPress cannot create the processing worker and falls back to server-side image generation. WordPress 7.1 also uses Document-Isolation-Policy: isolate-and-credentialless on applicable editor screens in supported Chromium browsers, so editor integrations that load cross-origin scripts, embeds, or resources should be tested carefully. (Make WordPress)

---

3. Make every custom block iframe-safe

WordPress 7.1 permanently removes the post editor’s non-iframe fallback.

In WordPress 7.0, inserting a block using API version 2 or earlier could still cause the post editor to render without an iframe. Beginning with Gutenberg 23.6 and WordPress 7.1, the post editor runs inside an iframe regardless of the API versions used by the blocks in the post. (WordPress Developer Resources)

Updating block.json is necessary:

{
	"apiVersion": 3,
	"name": "hooks-and-filters/example",
	"title": "Example Block"
}

But changing the number is not the migration.

You must verify that the block actually works inside an isolated editor document.

Stop using the global document and window

Editor scripts usually execute in the parent administration document. The block canvas now has its own document and window.

Code such as this is unsafe:

const element = document.querySelector(
	'.wp-block-hooks-and-filters-example'
);

window.addEventListener( 'resize', handleResize );

Obtain the document and window from the block’s own element instead:

import { useBlockProps } from '@wordpress/block-editor';
import { useRefEffect } from '@wordpress/compose';

export default function Edit() {
	const ref = useRefEffect( ( element ) => {
		const { ownerDocument } = element;
		const { defaultView } = ownerDocument;

		const handleResize = () => {
			// Recalculate the block using the iframe viewport.
		};

		defaultView.addEventListener( 'resize', handleResize );

		return () => {
			defaultView.removeEventListener(
				'resize',
				handleResize
			);
		};
	}, [] );

	const blockProps = useBlockProps( { ref } );

	return (
		<div { ...blockProps }>
			Example block
		</div>
	);
}

The official migration guide recommends deriving ownerDocument and defaultView from the relevant element, with useRefEffect() preferred when initialization and cleanup need to follow ref changes. (WordPress Developer Resources)

Audit more than direct DOM calls

Look for dependencies that internally assume a global browser document, including:

• Sliders and carousels
• Drag-and-drop packages
• Masonry and layout libraries
• Tooltip and popover systems
• Date or color pickers that create global portals
• Mutation and resize observers
• Keyboard shortcut listeners
• Fullscreen APIs
• Libraries that append elements directly to document.body

Whenever possible, pass the actual block element, target document, portal container, or window to the library.

When a third-party package cannot operate inside an iframe, submit or apply a patch that replaces global access with an element-relative document. Keep any temporary patch under version control and test it after every dependency update.

Load assets into the correct context

Use enqueue_block_editor_assets for scripts and styles belonging to the editor interface itself.

Use enqueue_block_assets for assets that style or operate on rendered block content and must be available inside the canvas as well as on the frontend.

Then verify all four locations independently:

Post Editor
Site Editor
Frontend
Frontend iframe or preview, when used by your product

A stylesheet appearing in the administration page does not prove that it loaded inside the editor canvas.

---

4. Remove obsolete editor component usage

WordPress 7.1 completes several previously announced migrations in @wordpress/components.

Form controls now render at a 40-pixel default height without requiring an opt-in prop. Passing __next40pxDefaultSize has no effect, and passing it as false no longer restores the old height.

The deprecated Navigation component and its subcomponents have been removed in favor of Navigator. The __experimentalApplyValueToSides utility has also been removed. In addition, the Emotion-specific css prop on View remains accepted for type compatibility but no longer produces styling. (Make WordPress)

Remove obsolete size props

Before:

<TextControl
	label="API key"
	value={ apiKey }
	onChange={ setApiKey }
	__next40pxDefaultSize={ false }
/>

After:

<TextControl
	label="API key"
	value={ apiKey }
	onChange={ setApiKey }
/>

Do not perform a blind global removal from every component. The 7.1 change applies to the documented form-control set; Button remains an exception and has not received the same change. (Make WordPress)

Visually test dense settings pages after removing the prop. A control growing from the previous size can expose:

• Fixed-height container bugs
• Misaligned labels and buttons
• Clipped validation messages
• Crowded table rows
• Overflow in plugin sidebars
• Incorrect vertical centering

Replace removed navigation components deliberately

A codebase containing this import requires attention:

import {
	Navigation,
	NavigationMenu,
	NavigationItem,
} from '@wordpress/components';

Move the interaction to Navigator, but do not treat the migration as a simple component rename. Navigation state, screens, back behavior, and component composition should be tested as a complete flow.

Replace Emotion-only View styling

Before:

<View
	css={ {
		padding: 16,
		maxWidth: 480,
	} }
/>

After, using a class:

<View className="my-plugin-settings-panel" />

.my-plugin-settings-panel {
	max-width: 30rem;
	padding: 1rem;
}

Or use style for truly dynamic inline values:

<View
	style={ {
		maxWidth: `${ panelWidth }px`,
	} }
/>

Static project-wide searches can locate most of these migrations quickly:

rg -n "__next40pxDefaultSize" .
rg -n "__experimentalApplyValueToSides" .
rg -n "\bNavigation(Menu|Item)?\b" src packages
rg -n "<View[^>]+css=" src packages

---

5. Test responsive styles and interactive states

WordPress 7.1 introduces editor-managed responsive styling, allowing users to store different block styles for desktop, tablet, and mobile views. It also adds interactive state styling for hover, focus, and active states.

Global interactive styles can apply across Button blocks, while per-instance interactive states are currently exposed for individual Button blocks. These areas remain important beta-testing targets and may receive fixes before the stable release. (Make WordPress)

This affects more than theme authors.

Plugins that parse, copy, normalize, sanitize, export, or regenerate block attributes must preserve style data they do not directly understand. A “cleanup” routine that reconstructs the style object from a hard-coded allowlist can silently delete responsive or state-specific values.

Audit these operations

Test any product that performs:

• Block duplication
• Pattern generation
• Style copying
• Global style synchronization
• Content migration
• Block JSON transformations
• AI-generated block markup
• Template exporting and importing
• Revision comparison
• Custom CSS generation
• Mobile preview controls

For every responsive test:

1. Set a value on desktop.
2. Set a different value on tablet.
3. Set another value on mobile.
4. Save and reload the editor.
5. View the frontend at each effective breakpoint.
6. Duplicate the block.
7. Copy and paste its styles.
8. Convert it to another block, when a transform exists.
9. Reset one viewport without resetting the others.
10. Export and re-import the containing pattern or template.

For state styling, verify keyboard focus as carefully as pointer hover. A visually attractive hover style can still create an inaccessible focus state if your theme or plugin overrides the generated output.

Custom design controls do not automatically gain responsive behavior merely because standard Core controls support it. Test how your own control writes attributes, how it knows the active preview, and whether its values survive serialization.

---

6. Check the persistent admin toolbar

The administration toolbar now appears in both the Post Editor and the Site Editor, except in contexts such as distraction-free editing. It also reflects the selected administration color scheme and incorporates several visual changes. (Make WordPress)

The practical implication is that nodes added through admin_bar_menu can now appear in editor contexts where the plugin may never have displayed them before.

Check for:

• Toolbar nodes overlapping editor controls
• Dropdowns hidden beneath editor layers
• Links that navigate away while unsaved changes exist
• Capability checks that assume a conventional administration screen
• CSS selectors that style the toolbar globally
• Nodes that make sense in wp-admin but not in the Site Editor
• Mobile toolbar overflow

When a node should not appear in block editors, remove it based on the current screen rather than relying on broad URL matching:

add_action(
	'admin_bar_menu',
	static function ( WP_Admin_Bar $admin_bar ): void {
		$screen = function_exists( 'get_current_screen' )
			? get_current_screen()
			: null;

		if ( $screen && $screen->is_block_editor() ) {
			$admin_bar->remove_node(
				'my-plugin-toolbar-node'
			);
		}
	},
	999
);

Do not hide every custom node by default. A well-designed status, preview, support, or workflow action may be useful inside the editor. The correct response is to test and intentionally support the new placement.

---

7. Validate Media Library infinite scrolling

WordPress 7.1 enables infinite scrolling by default in the Media Library grid and Media Modal.

Users with media-upload access receive a profile preference that can disable infinite scrolling and restore the Load more interaction. A callback attached to media_library_infinite_scrolling continues to take precedence over the user preference, but the filter’s default has changed from false to true. (Make WordPress)

Plugins extending attachment selection must test both states.

Pay particular attention to code that:

• Assumes a visible Load more button
• Counts only the attachments currently rendered
• Adds click handlers only during the first modal render
• Injects controls into attachment grids
• Implements custom filtering or search
• Maintains selected attachment state across additional loads
• Performs bulk operations
• Observes DOM nodes instead of using Backbone or media-frame events
• Assumes the initial collection is complete

To force the previous behavior across a site:

add_filter(
	'media_library_infinite_scrolling',
	'__return_false'
);

Avoid forcing the setting unless your product or site has a specific requirement. Otherwise, honor the user-level choice and make your extension function correctly in both modes.

---

8. Review parsers for editable blocks inside Custom HTML

WordPress 7.1 allows a Custom HTML block to contain editable, locked inner blocks between static HTML fragments.

A variation can define an innerContent array where null entries represent positions occupied by corresponding innerBlocks. The static shell remains intact while the nested blocks can be edited in place. Existing Custom HTML content continues to work as before. (Make WordPress)

This is particularly relevant to:

• AI content generators
• Visual HTML builders
• Import and export plugins
• Block validation tools
• Content sanitizers
• Migration scripts
• Headless WordPress serializers
• Static-site generators
• Translation workflows

Do not assume that core/html is always an opaque string with no nested block structure.

A parser should preserve the relationship between:

innerContent
innerBlocks
null placeholders
serialized block comments
static HTML fragments

A destructive normalizer might join the static fragments, discard the null placeholders, and consequently move or erase the editable content.

Build a regression fixture containing:

<!-- wp:html -->
<div class="notice">
	<header>Static heading</header>

	<!-- wp:paragraph -->
	<p>Editable paragraph.</p>
	<!-- /wp:paragraph -->

	<footer>Static footer</footer>
</div>
<!-- /wp:html -->

Pass the fixture through every parse, transform, export, import, synchronization, and AI-editing operation in your product. The serialized result should maintain the same static structure and inner-block position.

---

9. Adopt the new icon API progressively

WordPress 7.1 introduces public APIs for registering icon collections and individual SVG icons:

wp_register_icon_collection()
wp_unregister_icon_collection()
wp_register_icon()
wp_unregister_icon()
wp_get_icon()

Registered collections are exposed to the Core Icon block and through REST API endpoints. SVG input is sanitized against a deliberately narrow allowlist that currently permits svg, path, and polygon elements with limited attributes. Stroke-based icons are not yet a safe choice for this API; fill-based paths are more reliable. (Make WordPress)

A backward-compatible registration can look like this:

add_action(
	'init',
	static function (): void {
		if (
			! function_exists(
				'wp_register_icon_collection'
			)
		) {
			return;
		}

		wp_register_icon_collection(
			'hooks-and-filters',
			array(
				'label'       => __(
					'Hooks and Filters',
					'hooks-and-filters'
				),
				'description' => __(
					'Icons supplied by the plugin.',
					'hooks-and-filters'
				),
			)
		);

		wp_register_icon(
			'hooks-and-filters/hook',
			array(
				'label'   => __(
					'Hook',
					'hooks-and-filters'
				),
				'content' =>
					'<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">' .
					'<path fill="currentColor" d="M12 2v11a5 5 0 1 1-5-5h2a3 3 0 1 0 3 3V2z" />' .
					'</svg>',
			)
		);
	}
);

The function_exists() guard allows the same plugin release to continue loading on pre-7.1 installations.

Before adopting the API, test:

• Invalid or duplicate icon names
• Missing SVG files when using file_path
• Sanitization of every supplied SVG
• Accessibility labels
• Decorative icons without labels
• Color inheritance
• Icons in the Core Icon block
• REST API exposure
• Behavior when WordPress 7.1 is not installed

---

10. Review the new block and theme.json styling options

Most of the new design APIs are additive, but themes and block libraries should understand the data they introduce.

Background gradients alongside images

The new supports.background.gradient block support stores its value at style.background.gradient and renders it through background-image. Unlike the older color.gradient implementation, it can coexist with a background image instead of resetting it. (Make WordPress)

A custom block can opt in through block.json:

{
	"supports": {
		"background": {
			"backgroundImage": true,
			"gradient": true
		}
	}
}

A theme can provide a default:

{
	"version": 3,
	"styles": {
		"blocks": {
			"core/group": {
				"background": {
					"gradient": "var:preset|gradient|vivid-cyan-blue"
				}
			}
		}
	}
}

Test the final CSS when an image and gradient are both present. Products that sanitize inline style values must not accidentally strip the combined gradient-and-URL output.

Minimum-width support

Blocks can opt into minimum-width controls with:

{
	"supports": {
		"dimensions": {
			"minWidth": true
		}
	}
}

Themes can enable and define the value through settings.dimensions.minWidth and styles.dimensions.minWidth. The generated value maps to CSS min-width and can use dimension presets supplied by the theme. (Make WordPress)

Test flex and grid layouts carefully. A minimum width can create horizontal overflow when combined with fixed gaps, constrained parent widths, or non-wrapping containers.

Text shadow in theme.json

WordPress 7.1 recognizes textShadow under typography styles:

{
	"version": 3,
	"styles": {
		"typography": {
			"textShadow": "0 2px 8px rgba(0, 0, 0, 0.2)"
		},
		"blocks": {
			"core/heading": {
				"typography": {
					"textShadow": "0 1px 3px rgba(0, 0, 0, 0.25)"
				}
			}
		}
	}
}

The 7.1 implementation is intentionally limited to theme.json styling. It does not yet include a block-inspector control, a Global Styles editing interface, text-shadow presets, or per-block-instance support. (Make WordPress)

Do not document those missing interfaces as part of your theme’s 7.1 support.

---

11. Do not prepare for changes that are no longer shipping

Release roadmaps change. Compatibility work should follow the current beta and developer notes rather than early proposals or third-party summaries.

React 19 is not part of WordPress 7.1

WordPress 7.1 remains on React 18.3. The proposed React 19 upgrade was reverted after compatibility problems were found and is now available only as an experiment in the Gutenberg plugin for forward testing. (Make WordPress)

That does not mean React maintenance should stop.

You can still prepare for a future upgrade by checking that your build:

• Externalizes the WordPress-provided React runtime
• Does not bundle another React copy into editor packages
• Avoids legacy React APIs
• Does not directly bundle react/jsx-runtime
• Works with the Gutenberg React 19 experiment in a separate, non-blocking test job

Just do not claim React 19 as a WordPress 7.1 requirement.

Unicode email support was removed from the release

Unicode email-address support will not be included in WordPress 7.1. The work is continuing through a community plugin for broader compatibility and security testing. (WordPress.org)

Do not change production validation or database assumptions solely because an early 7.1 roadmap mentioned this feature.

The Classic block remains available

A proposal to hide the Classic block from the inserter was reverted. The block remains available in WordPress 7.1, and no user or developer migration is required. The temporary proposed filter associated with the removal was also withdrawn. (Make WordPress)

---

12. Run a targeted static audit

Automated searches will not prove compatibility, but they can quickly identify high-risk code paths.

Run an audit similar to this from your repository root:

# Blocks that have not migrated to API version 3.
rg -n '"apiVersion"\s*:\s*[12]' .

# Removed or changed editor component APIs.
rg -n \
	'__next40pxDefaultSize|__experimentalApplyValueToSides' \
	src packages

rg -n \
	'\bNavigation(Menu|Item)?\b' \
	src packages

# Global browser document access in editor code.
rg -n \
	'\b(window|document)\.' \
	src packages assets

# Media hooks that need client-pipeline review.
rg -n \
	'wp_image_editors|image_memory_limit|image_make_intermediate_size|wp_generate_attachment_metadata' \
	.

# Media Library and admin-toolbar extensions.
rg -n \
	'media_library_infinite_scrolling|admin_bar_menu' \
	.

# Block or HTML parsing code.
rg -n \
	'core/html|innerContent|innerBlocks|parse_blocks|serialize' \
	.

Treat every result as a review candidate, not automatically as a bug.

For example, using window for a plugin settings page may be valid. Using the global window to listen for events originating from an element inside the editor iframe probably is not.

---

13. Use a real compatibility test matrix

A single “activate the plugin and open a page” test is not enough.

Dimension	Minimum coverage
WordPress	Latest supported stable version and latest 7.1 pre-release
Editors	Post Editor, Site Editor, template editing, reusable patterns, and widgets when supported
Themes	One block theme and one classic theme
Browsers	Chrome or Edge for client media; Firefox and Safari for server fallback
Accounts	Administrator, Editor, Author, and any product-specific role
Media	JPEG, PNG, WebP, AVIF, HEIC, animated GIF, large images, and remote imports
Security headers	Normal configuration and production-like CSP
Content	Existing content, newly created content, invalid blocks, patterns, and synced patterns
Installation	Fresh install, update from previous version, activation, deactivation, uninstall
Network mode	Single site and Multisite when your product declares Multisite support
PHP	Oldest supported PHP version and the current production target
Build mode	Development assets and minified production bundle
Accessibility	Keyboard navigation, focus visibility, screen-reader labels, and zoom
Performance	Large media batches, content-heavy posts, and large Media Libraries

For WooCommerce extensions, add a representative matrix covering product editing, checkout blocks, cart blocks, order administration, email generation, and HPOS configurations supported by the extension.

---

14. Define the WordPress 7.1 release gate

A product should not be marked compatible because its homepage still loads.

Use an explicit release gate.

Code and build

• All custom blocks declare API version 3.
• Production JavaScript builds complete without warnings.
• PHP_CodeSniffer, PHPStan, ESLint, unit tests, and end-to-end tests pass.
• Removed component imports and utilities are gone.
• No unintended duplicate React runtime is bundled.
• Development and minified bundles behave identically.

Editor

• Blocks insert, edit, save, reload, duplicate, transform, and recover correctly.
• No iframe-related exceptions appear in the console.
• Editor content assets load inside the iframe.
• Plugin sidebars, toolbar actions, popovers, and modals display correctly.
• Keyboard and focus interactions work.
• Responsive and interactive-state styles survive a save-and-reload cycle.

Media

• Both client-side and server-side processing routes pass.
• Custom image sizes are generated.
• Metadata callbacks handle both creation and update passes.
• CDN, optimization, watermark, and offload operations are not duplicated.
• CSP configuration allows the intended route.
• HEIC, AVIF, GIF, remote images, and failed uploads have been tested where relevant.

Administration

• Custom toolbar nodes behave in the Post and Site Editors.
• Media Library extensions work with infinite scrolling enabled and disabled.
• Capability checks pass for non-administrator accounts.
• No layout regressions are introduced by 40-pixel form controls.

Distribution

• The changelog names any user-visible compatibility changes.
• The minimum supported WordPress version remains intentional.
• Upgrade routines have rollback or recovery coverage.
• A release candidate has been tested before updating Tested up to.
• Tested up to: 7.1 is added only after testing the final WordPress 7.1 build.
• The compatibility release is ready before or alongside the August 19 release.

---

Final readiness checklist

Before approving WordPress 7.1 compatibility, confirm that you have:

• Tested the current release candidate rather than relying only on an early beta.
• Read the final WordPress 7.1 Field Guide when it becomes available.
• Exercised both media-processing routes.
• Removed assumptions that images are always processed by PHP.
• Made media metadata callbacks idempotent.
• Migrated and tested every custom block inside the iframe editor.
• Replaced global document and window access where it targets block content.
• Removed obsolete component props, components, and utilities.
• Tested responsive and interactive style serialization.
• Verified custom toolbar nodes in both editors.
• Tested the Media Modal with infinite scrolling enabled and disabled.
• Preserved nested content inside core/html.
• Guarded optional 7.1-only PHP APIs for older installations.
• Tested updates using existing customer content.
• Completed accessibility, security-header, and role-based checks.
• Repeated the suite against the final WordPress 7.1 package.

Conclusion

The biggest WordPress 7.1 compatibility risks are not its visible interface changes.

They are architectural assumptions that may be buried inside existing products: that PHP always processes an image, that editor content shares the administration document, that media metadata arrives once, that a deprecated React component will remain available, or that Custom HTML can never contain nested blocks.

Products that explicitly test those assumptions should have a manageable upgrade.

Products that only update their compatibility header may discover the failures after their customers do.

WordPress 7.1 is scheduled for August 19, 2026. The best time to test the high-risk paths is during beta and release-candidate stages, while reproducible regressions can still be investigated before the stable release. (Make WordPress)

Official references

• WordPress 7.1 release schedule and milestones. (Make WordPress)
• WordPress 7.1 Beta 3 announcement. (WordPress.org)
• Official WordPress 7.1 testing guide. (Make WordPress)
• Client-side media processing developer note. (Make WordPress)
• Block migration guide for iframe compatibility. (WordPress Developer Resources)
• WordPress 7.1 editor component changes. (Make WordPress)
• WordPress 7.1 developer notes archive. (Make WordPress)