WordPress 7.1 Is Here: What Actually Changed, and What Might Break

What is new in WordPress 7.1? WordPress 7.1 adds native responsive block styles and pseudo-state controls to the editor, a public SVG Icon API, client-side media processing, a permanently iframed post editor, and expanded Abilities API tooling for AI and automation. It shipped on August 19, 2026, the closing day of WordCamp US in Phoenix, as the second major release of the year after 7.0 in May. The WordPress 7.1 update is worth taking, but it contains at least two changes capable of breaking older plugins.

WordPress 7.1 release date and the size of the release

The WordPress 7.1 release date was August 19, 2026, timed to the final day of WordCamp US in Phoenix. Anne McCarthy led the release, her first time in the role.

Numbers first, because they set expectations.

According to the WordPress 7.1 Field Guide published on August 5 by Milana Cap, this release contains more than 310 Core Trac tickets: over 100 enhancements and feature requests, and more than 180 bug fixes. On the Gutenberg side there are almost 600 enhancements and more than 630 bug fixes, drawn from Gutenberg 22.7 through 23.6.

The Field Guide also gives a diff between 7.0.2 and 7.1-beta4: 20 new hooks (19 filters and 1 action), 1,480 files changed, 88,163 insertions and 18,601 deletions.

That is a substantial release, not a point update. Accessibility received the most attention of any focus area with 46 tickets, followed by UI with 40 and administration with 28.

WordPress 7.1 also went through an unusually long release candidate phase. RC1 landed in early August, RC2 on August 6, RC3 on August 12, and an RC4 after that. RC3 was published in light of the WordPress 7.0.4 security release. Four release candidates tells you how much was still moving late in the cycle, which is worth remembering when you decide how quickly to apply the WordPress 7.1 update.

Responsive block styles in WordPress 7.1 are finally native

This is the feature most sites will actually feel, and it is the headline item on any list of WordPress 7.1 features.

Per the responsive block styles dev note, you can now define styles for tablet and mobile viewports in Global Styles per block type, and on individual block instances. In theme.json these nest under @mobile and @tablet keys:

json

"styles": {
  "blocks": {
    "core/group": {
      "spacing": { "padding": { "top": "3rem" } },
      "@mobile": {
        "spacing": { "padding": { "top": "1rem" } }
      }
    }
  }
}

There is no @desktop key by design. The block's default style is the desktop style, and it continues to apply at every viewport for any property you do not override.

The part theme developers have wanted for years is Trac ticket #65596: themes can set their own breakpoints through a new top-level settings.viewport property. Defaults are 480px for mobile and 782px for tablet. Values must be non-negative lengths in px, em, or rem. CSS functions, percentages, and unitless values are ignored. If your tablet value is equal to or lower than your mobile value, only mobile applies. It is a top-level setting, so you cannot configure it per block type.

The important limitation: blocks using standard block supports get responsive block styles for free, covering typography, color, background, border, dimensions, spacing, and layout. Blocks with custom style controls do not. If you or your developer built custom blocks, that is the line to check against.

Supporting responsive block styles meant changing block-level CSS in Core. Preset utility selectors are now wrapped in :where() to match root-level specificity. If your theme's custom CSS was relying on the old specificity to win a cascade fight, it may now lose one.

There is an opt-out if you do not want clients touching responsive controls:

php

add_filter( 'block_editor_settings_all', 'example_disable_responsive_editing' );

function example_disable_responsive_editing( $settings ) {
	$settings['responsiveEditingEnabled'] = false;
	return $settings;
}

Alongside it, pseudo-state styling landed. You can define :hover, :focus, :focus-visible, and :active in theme.json and through the editor UI, and these combine with responsive block styles. For now it is limited to the Button and Navigation Link blocks. Narrower than the headlines suggest, but it covers the two elements clients ask about most. A related fix, #64838, prevents pseudo-state styles leaking into the default state.

Practical effect for anyone running a block theme: a meaningful chunk of the custom CSS sitting in your child theme is now redundant. Not all of it. Enough that a cleanup pass is worth scheduling.

WordPress 7.1 breaking changes: the two most likely to bite

1. Post list table markup moved

This is documented, and it is the WordPress 7.1 breaking change being most under-reported.

Per changeset 62838 and the dev note, the primary th scope="row" in post list tables has moved from the checkbox column to the title column. The checkbox cell is now a td. The title cell is now a th carrying an aria-label with the post title. Collapsed cells in the responsive view use flex layout.

As accessibility work this is correct and overdue. Screen readers now identify each row by the post it contains rather than by a checkbox that may not even be present. It pairs with #64932, which makes subpage hierarchy in post list tables accessible.

The risk is that this markup has been largely unchanged since 2010, and a lot of plugins depend on it implicitly. Specifically, check anything that:

• selects th.check-column in CSS or JavaScript

• expects row actions or post titles to sit inside a td

• adds custom columns to post, page, product, or custom post type list screens

For a WooCommerce store, that last one is not hypothetical. Order and product list screens are heavily extended by third-party plugins. This will not throw a white screen. It will show up as a misaligned column, a bulk action that stops responding, or an admin script that fails silently.

2. Block CSS is now conditional, and it is not in the dev notes

The second of the WordPress 7.1 breaking changes deserves your attention because it has not been written up anywhere official.

In the comments on the Field Guide, contributor Jason LeMahieu reported that testing showed a change in how and when block CSS is included. His example: the CSS for Cover blocks is now output only when the page actually contains a Cover block. He flagged this as a potential breaking change for sites that pull in content remotely, and asked whether it could be documented. Core contributor Adrian Duffell replied on August 17 agreeing it should be noted somewhere and asking for a Gutenberg issue.

As of the WordPress 7.1 release date, there is no dev note covering it.

If your site renders content fetched from elsewhere, uses a headless or partially decoupled setup, or caches block markup separately from the page that generated it, test this directly. Load a page whose block markup came from somewhere other than that page's own render, and check whether it still has styles.

Other WordPress 7.1 features worth knowing

The post editor is always iframed now. In 7.0, WordPress decided per post whether to iframe the editor based on the blocks present, so the editor could switch modes depending on content. That conditional behaviour is gone, including for sites registering legacy meta boxes. Most blocks work unchanged. Failures nearly always trace to one cause: the iframe has its own document and window, so code reaching for the global document or window to touch the canvas is addressing the wrong document. The fixes are getting the canvas document via ownerDocument and defaultView, and using useRefEffect for listeners.

jQuery UI moved to 1.14.2. Called out in the Field Guide as the most notable external library change, and flagged for testing if you run plugins depending on jQuery UI behaviour or styling. Older plugins with datepickers, sortables, or dialogs are the usual suspects.

Media Library infinite scrolling is on by default, with a per-user opt-out. Clients used to pagination notice this on day one, so mention it before they file a support ticket.

Client-side media processing arrived. New APIs let supported image operations run in the browser before upload, with REST API changes for validating dimensions, size-aware encode quality, and registering one sideloaded file under multiple image sizes.

The SVG Icon API is public. WordPress 7.0 bundled editor icons. WordPress 7.1 makes it a registerable API with wp_register_icon_collection(), wp_register_icon(), and wp_get_icon(). Two constraints: SVGs are sanitised through wp_kses against a conservative allowlist of only <svg>, <path>, and <polygon>, and fill is permitted on shapes but not the outer <svg>, so a standalone wp_get_icon() call renders black rather than inheriting text colour.

The Abilities API became usable. Introduced as infrastructure in 6.9, it now has execution lifecycle filters, filtering via wp_get_abilities(), a unified public exposure flag, and JSON Schema preparation for external clients. If you are building AI or automation tooling on WordPress, this is the release where it stops being a foundation and becomes a toolkit.

Gradients and background images can coexist. The new background.gradient support renders through the background-image longhand instead of the background shorthand, which previously reset background-image and forced a choice between the two. Core opts in Group, Accordion, Pullquote, Post Content, and Quote.

What did not ship: React 19 was deferred again after incompatibilities surfaced, and continues as a Gutenberg experiment. Core stays on 18.3. Real-time collaboration was tested extensively but is not enabled. The proposal to hide the Classic block from the inserter was reverted on July 7, so the Classic block stays.

Should I update to WordPress 7.1? A testing checklist

Should I update to WordPress 7.1 right now is the wrong question. The right one is what you test first. Not "test on staging." Specifically:

1. 1. Take a backup and restore it once to a throwaway environment. An untested backup is a hope.

2. 2. Open every post-type list screen in the admin, including WooCommerce products and orders. Check column alignment, then run a bulk action on a single item.

3. 3. Open the post editor on a page using custom blocks or legacy meta boxes. The permanently iframed editor surfaces problems here first.

4. 4. Load any page rendering remotely-sourced or separately-cached block content and confirm it still has styles, per the conditional block CSS issue above.

5. 5. Exercise anything using a datepicker, sortable list, or modal in wp-admin for the jQuery UI 1.14.2 update.

6. 6. Check custom CSS that fought a specificity battle with preset classes, now that they are wrapped in :where().

7. 7. Confirm every plugin has shipped a compatible version before you push the WordPress 7.1 update to production.

For most established sites, wait one to two weeks so plugin authors can catch up. A brand new site with a small plugin footprint has no reason to start on 7.0.

Running WordPress or WooCommerce for a business and no one has audited your plugin stack in a while? This release is a good reason to. We handle WordPress and WooCommerce builds and maintenance for clients across the US, UK, and Canada. See our work or book a call.