Ensure compatibility with WordPress 7.1

[utkarshcloudinary]

Approach

WordPress 7.1 (scheduled 19 Aug 2026) enforces the iframed block editor for block themes and ships React 19. Tested against 7.1-beta3 and fixed the incompatibilities found:

Gallery block

• Upgraded the block to API v2 and wrapped edit output in useBlockProps() so it renders inside the enforced iframe.
• Moved the block editor stylesheet from enqueue_block_editor_assets to enqueue_block_assets so WP injects it into the editor iframe correctly.
• Moved render-time setAttributes() calls into useEffect (React 19 warns on state updates during render).
• Fixed the generated container id which produced undefined<id> under API v2, since className is no longer passed to Edit.
• Replaced the hand-written wp-editor (deprecated) dependency list for gallery-block.js with the webpack-generated gallery-block.asset.php dependencies.
• Save markup is deliberately unchanged, so existing content stays valid with no deprecation/migration needed.

Core image/video inspector

• Moved a render-time setAttributes() into useEffect.
• Switched InspectorControls from the deprecated wp.editor alias to wp.blockEditor, then converted the wp.hooks/wp.blockEditor global usages to proper @wordpress/hooks / @wordpress/block-editor imports so the dependency extraction plugin detects them.
• class-video.php now consumes the generated block-editor.asset.php instead of a hand-written dependency list. The previous static list compensated for the globals the extraction plugin couldn't see, but omitted wp-api-fetch (a real import in blocks.js) which only worked because other editor scripts loaded it first.

Gallery settings page

• Fixed a duplicate enqueue of js/gallery.js (loaded under both the gallery_config and gallery-widget handles), which executed the bundle twice and called createRoot() twice on the same container — reported as a console error by React 19 on every settings page load. Pre-existing issue surfaced by the React 19 testing.

Design decisions

Why block API v2 and not v3? readme.txt declares Requires at least: 5.6. API v2 is supported since WP 5.6 and is iframe-compatible, so it satisfies 7.1 without dropping supported versions. API v3 requires WP 6.3+ and would break 5.6–6.2. WP 6.9+ logs a console deprecation nudging blocks to v3; that's cosmetic and can be revisited when the plugin's minimum WP version is raised.

Why no shims for React 19 vs React 17 (WP 5.6)? React ships with core and is consumed only via @wordpress/element. useEffect and useBlockProps both exist in 5.6, so one codebase covers 5.6 → 7.1. The single standalone React root (settings-gallery.js) already had a createRoot-with-render fallback.

Why no block deprecation entry? The save markup is unchanged (bare container div, no useBlockProps.save() wrapper). The front-end render only mounts the widget into '.' + attributes.container and never depends on a block wrapper class. With identical save output, old content stays valid by definition — verified by loading legacy v1 markup under the new code (isValid: true, zero validation warnings).

Known follow-up: editor.MediaUpload filter in featured-image.js extends core's class component. Core still ships it as a class (kept deliberately for plugin compat) but has deprecated the pattern; migrating to composition is future work, not a 7.1 blocker.

QA notes

Environment: wp-env with core: https://wordpress.org/wordpress-7.1-beta3.zip, PHP 8.2, WP_DEBUG + SCRIPT_DEBUG, twentytwentyfive (block theme, so the editor iframe is enforced).

1. Insert a Cloudinary Gallery block in the post editor — placeholder and inspector controls should render inside the iframe with no console errors.
2. Add images, save, reload — block stays valid (no "Attempt Block Recovery" prompt) and the container id has no undefined prefix.
3. Open a post containing legacy gallery block markup (created on the previous plugin version) — it should load with isValid: true and zero validation warnings.
4. Insert a core Image block with an asset that has Cloudinary transformations — the Transformations panel appears (Block → Settings tab) with no React "update during render" warning in the console.
5. Insert a core Image/Video block and confirm the Cloudinary filters still apply: overwrite_transformations attributes exist on both block types and the editor.MediaUpload featured-image filter is registered.
6. Verify no ...was added to the iframe incorrectly warning for cloudinary-gallery-block-css.
7. Open Cloudinary → Gallery settings — the settings UI and live widget preview render, js/gallery.js loads only once, and there is no createRoot() console error.
8. Publish and view the post on the front end — gallery container renders, no PHP notices.