WordPress 7.1 Ships Alongside WordCamp US: What Agencies Need to Test Before Client Sites Update

WordPress 7.1 is scheduled to land on August 19, the closing day of WordCamp US in Phoenix. Release Candidate 1 arrived on August 5 carrying more than 145 changes since Beta 4 — 57 in the editor and 88 in core — and the release squad has held the date through the RC cycle.

For agencies maintaining client sites, the headline features are not the risk. The Icons API, shareable revisions, @mention notifications in Notes, and speculative-loading configuration are additive; they do not remove anything a working site depends on. The risk sits in three quieter changes that alter markup, component props, and rendering context — the kind that produce a subtly wrong admin screen rather than a fatal error, and therefore get discovered by the client rather than by you.

The list table markup change

The most consequential breaking change for custom work: in post list tables, the primary th scope="row" moved from the checkbox column to the title column.

This is a correctness fix — the title is the row’s actual header — but it invalidates any code that assumed the old structure. That includes custom columns registered through manage_posts_columns where positional logic or CSS targets the first cell, admin stylesheets written with :first-child or nth-child selectors against the list table, and any JavaScript walking the row to find the checkbox by header position.

Nothing here throws an error. The column shifts, the styling lands on the wrong cell, and the screen looks broken in a way that reads as “the update broke our site.” Any client with custom post types and a customized admin list view needs this checked specifically.

Deprecated size props on form controls

The __next40pxDefaultSize prop is now non-functional, and the size prop is deprecated on several form controls. Both need to be removed rather than adjusted.

__next40pxDefaultSize spread widely through custom blocks and plugin settings panels during the period when it was the recommended opt-in to the newer control sizing. A great deal of agency block code carries it, often copied from documentation examples years old at this point. It is now inert — passing it does nothing, which means components that relied on it for sizing will render at whatever the current default is instead.

Audit any custom block’s edit component, any settings panel built on @wordpress/components, and anything scaffolded from an older create-block template.

The editor always renders in an iframe now

The post editor previously switched between iframed and non-iframed rendering depending on theme type and block content. That conditional behavior is gone — the post editor now always renders inside an iframe.

This is the change most likely to surprise agencies, because the sites that were getting non-iframed rendering were disproportionately the ones with older custom blocks and classic-adjacent setups. Anything that assumed editor content shared a document with the admin page is affected: styles enqueued to the admin rather than through enqueue_block_assets, scripts reaching into editor content with document.querySelector, and third-party plugins that inject into the editor DOM.

If a client’s editor experience depends on a plugin that has not been updated recently, this is where it will surface.

Smaller items worth a look

• Navigation blocks no longer propagate font-size to child elements. Menus that inherited their sizing this way will change appearance. Check any theme where navigation typography was set at the block level rather than on the items.
• Block transforms can now target a specific variation via a new variationName parameter — useful rather than risky, but it changes what a transform registration can express.
• Responsive editing can be disabled through the block_editor_settings_all filter, which is worth knowing for clients whose editors find the responsive controls confusing.
• __experimentalCloneSanitizedBlock and __experimentalSanitizeBlockAttributes are stabilized. The old names still work but emit deprecation notices, so console noise in a client’s editor may be traceable here.
• React stays at 18.3. The React 19 migration is postponed, which removes a category of concern from this release but defers it to a future one.

A practical sequence

Test on a staging copy, not a fresh install. The changes above are all interactions between core and existing custom code — a clean WordPress with a stock theme will pass every one of them and tell you nothing.

Run the update against staging, then walk the admin screens a client actually uses daily: the post and custom-post-type list views, the editor with the site’s real templates loaded, and any settings panels the agency built. Look for visual drift rather than errors. Open the browser console while editing and read the deprecation notices — in this release they are unusually informative about which of your components need attention.

WordPress core’s own guidance during the RC period was explicit that pre-release builds do not belong on production or mission-critical sites. That caution expires on the 19th for core itself, but not for the plugin ecosystem around it. The plugins a client depends on will not all have tested against an always-iframed editor by release day, and the sensible posture for managed client sites is to let point releases accumulate for a short while before rolling the update out broadly.

The agencies that get burned by a WordPress release are rarely the ones that read the field guide. They are the ones that let auto-updates carry a major version onto forty client sites on a Wednesday.