How to Prepare Your Plugin or Theme for WordPress 7.1

You have the map. This last tutorial is the process: take a plugin or theme from “untested on 7.1 RC” to “safe to recommend the update.”

The process

Spin up WordPress 7.1 in isolation

Never test on production. Use the WordPress Beta Tester plugin (Bleeding edge / RC), a direct RC zip, WP-CLI, or WordPress Playground. Install your plugin and a representative theme. Turn on WP_DEBUG and WP_DEBUG_LOG.

Confirm the post editor is iframed

Open a post that contains only your blocks, including one with a legacy meta box if you still ship those. The canvas must be an iframe. Click, type, open inspector controls, drag InnerBlocks. Watch the console for null query results and CSS that never applies.

Replace global document / window access

Search your editor JS for document. and window. used against the canvas. Switch to ownerDocument / defaultView and useRefEffect for listeners. Re-test popovers, drag handles, and any getBoundingClientRect logic. See Part 4.

Exercise media uploads on Chromium and Firefox

On Chrome/Edge: upload JPEG, PNG, a HEIC if you have one, an opaque GIF, and an AVIF. Confirm thumbnails appear and your wp_generate_attachment_metadata callback runs twice (create then update). On Firefox: confirm the server fallback still hits your hooks. If you cannot tolerate client-side files, filter wp_client_side_media_processing_enabled. Details in Part 2.

Audit abilities for public vs permission

If you registered abilities in 7.0, decide per ability: meta.public => true (all clients) vs show_in_rest only. Keep permission_callback. Add wp_ability_invoked logging without dumping raw input. Hit REST GET run endpoints and confirm integers/bools arrive typed. Part 3.

Check admin bar, jQuery UI, and notifications

Open Site Editor with your toolbar node. Hide it on $screen->is_block_editor() if it does not belong. Click every jQuery UI widget you still ship (1.14.2). If you filter notify_post_author, confirm your return value is now final.

Ship a 7.1-tested tag and say so

Bump “Tested up to: 7.1” only after the list below is green. Mention iframe + media fallback in the changelog so hosts and agencies know you did the work.

Before you ship

WordPress 7.1 compatibility

0 / 14

What did not make WordPress 7.1

Plan against this list. Several items were discussed loudly during the cycle and then did not ship.

Requested in the 7.1 cycle

Shipped · Always-iframed post editor
Shipped · Client-side media
Shipped · Abilities public flag
Shipped · Design System tokens (foundation)
Planned · Real-time collaboration
Planned · React 19 in Core
Planned · On This Day widget

Classic block — an early proposal would have hidden it from the inserter for new content. After testing, Core reverted. The Classic block stays. Do not write a “Classic is gone in 7.1” blog post. Stays in the inserter.

React 19 — punted beyond 7.1; remains an experiment in the Gutenberg plugin. Announcement.

Real-time collaboration — extensive outreach and testing, not enabled in the release. Conflict handling and Core integration continue. Outreach post.

“On This Day” widget — considered, not included. Follow #65801.

Merge proposals — Guidelines built on Knowledge, and Design System Theming, landed foundations (tokens) while the broader products keep iterating. Do not treat a merge proposal as a shipped product.

Sometimes what we don’t add is more valuable than what we do.

— Anne McCarthy, 7.1 release leads

Do not promise customers collaborative editing, React 19, or a hidden Classic block on WordPress 7.1. Promise an iframed editor that works, images that process in the browser, and abilities that clients can actually discover.

Frequently asked questions

Preparing for WordPress 7.1

Is WordPress 7.1 a breaking release for block plugins?

Yes for plugins that touch the post-editor canvas via the global document or window, or that inject canvas CSS only into the admin page. Most API v3 blocks already work. Test anyway — 7.1 removes the last non-iframe fallback.

Will my image-watermark plugin break?

Not if wp_generate_attachment_metadata is idempotent. It still fires on create and again on update after finalize. Test Chromium (client-side) and Firefox (server fallback).

Should I set meta.public on every ability?

Only when the ability is intended for external clients (REST, MCP, agents). Keep permission_callback. Use show_in_rest when exposure should stay REST-only.

Is collaborative editing in WordPress 7.1?

No. It was tested during the cycle and is not enabled in the release.

Where is the official Field Guide?

https://make.wordpress.org/core/2026/08/05/wordpress-7-1-field-guide/ — this series is a developer walkthrough of that document, not a replacement.

That is the 7.1 series. For the AI substrate this release hardens, keep the WordPress 7.0 series next to it — 7.1 assumes you already registered abilities; 7.0 explains why they exist.