WordPress 7.1 “Mary Lou”: what actually changed, and what to test before you update

WordPress 7.1 “Mary Lou” shipped on 19 August 2026, named for the jazz pianist, arranger and composer Mary Lou Williams. It is a substantial release by any measure: more than 1,500 enhancements and fixes from over 800 contributors, 170 of them contributing for the first time, with full translations in more than 20 locales on day one. It folds ten Gutenberg plugin releases, 22.7 through 23.6, into core.

Most release write-ups list the features. This one is organised around a different question: what actually changes for you, and what should you check before you click update. Because one thing in 7.1 will break sites, and it is not the thing the screenshots are about.

The short version

• Styling that used to need CSS no longer does. Blocks can carry Mobile and Tablet overrides on top of their base style, and hover, focus and active states are now editable in Global Styles.
• Media was rebuilt. Image processing moved into the browser, there is a proper crop modal instead of the old inline tool, and HEIC, AVIF and HDR files upload natively.
• The editor got less disorienting. The admin bar follows you in, notes support rich text and @mentions, and revisions have shareable links.
• Two new core blocks: Tabs and Playlist.
• The post editor is now always iframed. This is the breaking change. Blocks registered at Block API v2 or lower need migrating.

Change	Who it affects	Action needed
Always-iframed post editor	Block and plugin developers	Yes: migrate to Block API v3, test editor injection
jQuery UI 1.14.2	Anything using jQuery UI widgets	Yes: test date pickers, sortables, dialogs
Client-side media processing	Everyone who uploads images	Test uploads; a filter disables it
Responsive styles	Theme authors, site builders	Optional: defaults apply if you do nothing
Pseudo-state styling	Theme authors	Optional
Tabs and Playlist blocks	Editors	None

Responsive styles, without touching CSS

This is the headline feature, and it closes a gap that has annoyed people since the block editor shipped. Until now, making a heading smaller on phones meant writing custom CSS somewhere: a child theme, the Additional CSS box, or a plugin. There was no way to say “this, but smaller on mobile” inside the editor.

In 7.1 every block that uses the core block supports (typography, colour, background, border, dimensions, spacing and layout) can carry Mobile and Tablet overrides on top of its base style. Block style variations get the same treatment.

In the editor

Switch the editor’s device preview between Desktop, Tablet and Mobile, then style the block as normal. A badge tells you which viewport you are editing, so you do not accidentally restyle desktop while looking at a phone frame. It works in two places: in Global Styles, where it applies to every instance of a block type, and on an individual block.

In theme.json

The same thing is expressible in theme.json with two new keys, @mobile and @tablet, nested inside a block’s styles:

"styles": {
  "blocks": {
    "core/heading": {
      "typography": { "fontSize": "3rem" },
      "@tablet": {
        "typography": { "fontSize": "2.25rem" }
      },
      "@mobile": {
        "typography": { "fontSize": "1.75rem" }
      }
    }
  }
}

Note that this is not mobile-first. The base style applies everywhere unless a narrower viewport overrides it. The generated media queries are:

• @mobile becomes @media (width <= 480px)
• @tablet becomes @media (480px < width <= 782px)

WordPress writes this out under a generated class. Per-instance declarations that are not layout-related get !important, because they have to beat the inline styles the block already emits. Worth knowing if you are ever debugging why your own stylesheet suddenly lost an argument.

Custom breakpoints

480px and 782px are defaults, not laws. A new top-level settings.viewport key lets a theme move them:

"settings": {
  "viewport": {
    "mobile": "30rem",
    "tablet": "45rem"
  }
}

Three constraints are worth committing to memory. Only px, em and rem are accepted. CSS functions, percentages and unitless values are ignored. If the tablet value is less than or equal to the mobile value, WordPress uses the mobile breakpoint only. And settings.viewport is genuinely top-level: you cannot give different blocks different breakpoints.

If you would rather editors did not have this power at all, setting responsiveEditingEnabled to false removes both entry points from the editor. Responsive styles already saved in theme.json keep rendering on the front end: the setting governs the interface, not the output.

Hover, focus and active states in Global Styles

The second half of the styling story. Four pseudo-states are now editable without CSS: :hover, :focus, :focus-visible and :active. In 7.1 they apply to the Button and Navigation Link blocks, exposed through a State dropdown in the block sidebar. If you change a state locally and then push it to Global Styles, the editor shows a review step first rather than silently restyling every button on the site.

States compose with breakpoints, and the nesting order matters: viewport on the outside, state on the inside.

"styles": {
  "blocks": {
    "core/button": {
      "color": {
        "background": "var:preset|color|accent-1",
        "text": "var:preset|color|base"
      },
      ":hover": {
        "color": { "background": "var:preset|color|accent-2" }
      },
      "@mobile": {
        ":hover": {
          "color": { "background": "var:preset|color|contrast" }
        }
      }
    }
  }
}

Individual blocks carry the same structure inside their style attribute in the post markup, so a one-off hover colour on a single button is stored with that button rather than in the theme.

There is also a quieter addition: custom states, prefixed with a hyphen. These are theme.json-only with no user-facing interface, and right now only the Navigation Link block ships one: -current, for styling the current menu item, which previously meant hunting for .current-menu-item by hand. A block declares its own states in block.json:

"selectors": {
  "states": {
    "-current": ".wp-block-navigation-link .current-menu-item"
  }
}

As with responsive editing, blockStatesEditingEnabled set to false hides the interface without dropping styles that are already saved.

Media: processing moved into the browser

This is the change with the widest blast radius, and if it works properly most people will never notice it. That is rather the point.

What client-side processing changes

Until now every upload went to PHP. GD or ImageMagick resized the file, generated the sub-sizes, and wrote them to disk. That is where “the image could not be processed” comes from, and it is why a 12-megapixel photo can exhaust the memory limit on modest shared hosting.

In 7.1 the supported operations run in the browser first, using a WebAssembly build of libvips, and the browser hands the server files that are already processed. The practical effects:

• Large photos stop dying on PHP memory limits
• Server CPU during a bulk upload drops sharply, because the work happens on the machine doing the uploading
• HEIC files straight off an iPhone convert on the way in, instead of being rejected
• AVIF, WebP and HDR gain maps are handled natively
• Uploads survive a dropped connection, pausing and resuming rather than starting over

The catch is browser support. The full pipeline needs a current Chromium-based browser; everything else falls back to the old server-side path. Both routes produce a working upload, so nothing is broken either way. Only the location of the work changes. Hosts and plugins that need the previous behaviour can switch it off with the wp_client_side_media_processing_enabled filter.

If you run an image optimisation plugin, this is the one to test properly. Its assumptions about when and where a file gets touched may no longer hold.

The new crop modal

The old inline cropping tool is gone, replaced by a dedicated modal: freeform and preset aspect-ratio cropping, flip, precise rotation, a magnified view while you drag, pixel-snapping handles, and metadata editing in the same window. It opens from the Image block and, usefully, from inside a Cover block, which previously meant leaving the editor for the media library.

The rest of the media changes

• The Media Library grid now uses infinite scrolling by default, with a per-user option to go back to pagination
• Galleries can populate dynamically from a post’s own attachments, instead of being a fixed list
• An “Attached images” section in the inserter
• Columns and Gallery blocks transform into Grid layouts without losing content
• Background images and gradients can be layered on the same block
• A decorative-image toggle that marks an image as presentational for screen readers, rather than forcing an empty alt attribute by hand
• On multisite, upload limits now apply to URL-based media sideloading too

Two new core blocks: Tabs and Playlist

Tabs organises content into clickable panels. The notable part is not the block, it is that core built it against the W3C ARIA Authoring Practices: correct roles, correct keyboard navigation, correct focus handling. That is precisely the part hand-rolled tab plugins get wrong, and it is the reason to switch. Tabs can be reordered from the toolbar.

Playlist displays a collection of audio files with track metadata, artwork and an optional waveform view. If you publish a podcast, this replaces a shortcode or a plugin with a core block.

There is also an Icon block, with an icon picker plus flip and rotate controls, which leans on the new icon registration API described further down.

The admin bar now follows you into the editors

A small change that removes a persistent papercut. The toolbar now stays visible in the post editor and the site editor, so the route between the front end, the dashboard and the editors is the same everywhere instead of a dead end you escape with the browser back button. It has been redesigned along the way: a chevron back button, the site icon, circular avatars and SVG icons throughout.

The rest of the admin housekeeping in this release:

• The command palette (Ctrl/Cmd + K) groups results into Recent, Matching and Suggestions, and remembers history within a session
• The site editor finally respects your admin colour scheme
• A new Design › Identity screen groups site title, tagline, logo and site icon in one place
• The posts list shows excerpts, which makes scanning a list of similarly-titled drafts far less painful
• Shift-click selects a range in list tables for bulk actions
• A comment’s parent can be reassigned from the interface instead of the database

Notes, mentions and shareable revisions

Notes, introduced as a way to leave feedback on blocks, grew up in 7.1. They support rich text (bold, italic, code, links and emoji) plus @mentions that trigger an email. You can attach a note to a specific text selection rather than a whole block, keep several threads on one block, and long notes collapse instead of swallowing the sidebar. Notes are stored as a dedicated comment type and kept out of public comment feeds.

Revisions became addressable at the same time. You can generate a link to a specific revision and send it to someone; they open that exact version with the changes colour-coded. The revision picker was reworked to match. For anyone who has ever tried to describe a change over chat by version number, this is a genuine improvement.

What developers need to look at

The post editor is always iframed now

This is the change to test first. Previously the post editor only used an iframe under specific conditions: a block theme, no legacy meta boxes, and every registered block at Block API version 3. In 7.1 it always iframes, legacy meta boxes included.

The consequences are concrete:

• Blocks registered at Block API v2 or lower need migrating to v3 to render correctly in the canvas
• Any JavaScript that queries the editor DOM from outside, such as a document.querySelector aimed at the canvas, now has an iframe boundary in the way
• Editor CSS injected the old way may simply not reach the canvas. Use add_editor_style(), or enqueue on enqueue_block_assets, which is injected into the iframe

Consistent iframing is the right call: editor styles are properly isolated and the canvas finally previews what the front end renders. But “the right call” and “will not break your site on Tuesday” are different claims.

jQuery UI 1.14.2

Bundled jQuery UI moved to 1.14.2. Anything leaning on jQuery UI widgets (date pickers, sortables, dialogs, the older admin interfaces plugins still ship) deserves a click-through. This is the classic source of the bug that only surfaces on one settings screen nobody visits until month end.

The SVG Icon API

Icons are now a core concern rather than something every plugin reinvents. wp_register_icon_collection() registers a namespaced set, wp_register_icon() adds a single icon, and wp_get_icon() renders one, with SVG input sanitised on the way in. If you maintain a plugin that ships its own icon sprite, this is worth adopting: it deduplicates markup and gives the Icon block something to pick from.

Abilities API and the design system

The Abilities API, which gives AI agents and MCP integrations machine-readable descriptions of what a site can do, picked up filtered discovery through wp_get_abilities(), execution lifecycle hooks, a unified public exposure flag, custom validation, and JSON Schema compatibility. Execution now checks is_ability_call() before running.

Alongside it, a new @wordpress/theme package introduces design tokens and a ThemeProvider, so plugin screens can inherit WordPress’s own theming instead of guessing at hex values and drifting out of sync every release.

Smaller things worth knowing

• wp_get_tooltip() and wp_get_toggletip() provide a shared accessible tooltip mechanism, replacing title attributes that screen readers never handled well
• The notify_post_author filter now has the final say over author notifications
• get_file_data() recognises headers preceded by <? tags
• Templates gained a date field
• WP_Theme::get_post_templates() is faster on themes with a lot of templates
• Editor startup is quicker thanks to preloaded REST API requests
• Block Bindings now reach List Item blocks

What didn’t make the cut

Worth knowing, if only so you stop waiting for them:

• Real-time collaborative editing. Tested but not enabled. Still being developed in the Gutenberg plugin.
• React 19. Deferred over compatibility concerns.
• The “On This Day” dashboard widget. Postponed.
• Hiding the Classic block from the inserter. Planned, then reverted after feedback. It is still there.

Before you update

7.1 is a feature release with a real breaking change in it. The always-iframed editor is not a “probably fine” item if you run custom blocks or a plugin that injects into the editor. A sensible order:

1. Take a backup you have actually restored from. An untested backup is a hypothesis, not a safety net. If you have never run the restore, you do not know what you have.
2. Update a staging copy first, not production. A clone of the real site, with the real plugins, not a clean install.
3. Open the post editor on a page that uses your custom and third-party blocks. Anything at Block API v2 or below is the likely casualty.
4. Upload a large photo and a HEIC file. Confirm the client-side path works, then try a non-Chromium browser to confirm the server-side fallback does too.
5. Exercise anything using jQuery UI. Date pickers and sortables in admin screens, especially in older plugins.
6. Check your admin list tables, particularly where plugins add columns or bulk actions.
7. If you maintain a theme, decide whether to declare settings.viewport. Doing nothing is a valid answer; you get 480px and 782px.
8. Then update production, in a window where you can roll back without an audience.

Steps one and two are where Backvera fits. Backups are incremental and driven server-side, so the copy you take before an update reflects the site as it is now rather than whatever last night’s cron managed, and it is stored off-site rather than on the machine you are about to change. Restores are one click and finish with an atomic swap: the site stays on the current build until the new one is verified, so a restore that fails does not leave you half-migrated. Restoring into a staging clone is the same operation, which is what makes step two cheap enough to actually do instead of skip.

Whatever you use, the test is the same: if 7.1 breaks a block on your site, can you be back on the previous version in minutes, from a copy you have watched restore successfully at least once? If the answer is no, that is the thing to fix before you touch the update button.

None of this is exotic advice. It is just the difference between an update and an incident.