news 7 min read

WordPress 7.1 “Mary Lou” Is Out: What Shipped and What to Do This Week

WordPress 7.1 released August 19, 2026 with responsive styling, browser-side media processing, and a fully iframed post editor. The agency update plan.

Dobromir Dechev
Dobromir WordPress agency owner
Quick answer

WordPress 7.1 “Mary Lou” shipped on August 19, 2026 during WordCamp US, named for jazz pianist Mary Lou Williams and built by more than 800 contributors across 1,500+ enhancements and fixes. The headline features are responsive and pseudo-state styling in theme.json, a rebuilt media pipeline that compresses and resizes images in the browser via WebAssembly, richer Notes with @mentions, and two new blocks. The change most likely to generate support tickets is not on the feature list: the post editor is now iframed on every theme, with no escape hatch. This is what actually shipped, what breaks, and a staged plan for updating a client portfolio this week.

WordPress 7.1 “Mary Lou” shipped on August 19, during WordCamp US, exactly on the date the release schedule promised back in June. More than 800 contributors worked on it, 170 of them for the first time, across more than 1,500 enhancements and fixes. Anne McCarthy led the release. Twenty-plus locales were fully translated on day one.

The name honours Mary Lou Williams, the jazz pianist and arranger who started performing publicly at six and whose Harlem apartment became the workshop where Monk, Gillespie, and Powell hammered out bebop.

That is the announcement. Here is the part the announcement does not cover: what this does to a portfolio of client sites, and in what order to touch them.

What actually shipped

Responsive and pseudo-state styling. The headline for most people. You can now style blocks at different breakpoints directly in the Site Editor, and theme authors get hover, focus, focus-visible, and active states through theme.json. Things that previously required custom CSS are now editor controls. For agencies, this is the first release in a while that removes work from the stylesheet rather than adding to it.

A rebuilt media pipeline. Image compression, resizing, and thumbnail generation now run in the browser through a WebAssembly build of libvips instead of on your server. That takes real load off PHP and removes a familiar class of support ticket — the memory-limit failure and the gateway timeout on a client uploading 12MP photos straight off a camera. Core also adds native AVIF, HEIC, and HDR gain map support, opt-in GIF-to-video conversion, upload progress indicators, and automatic retries when a connection drops.

A proper media editor. A modal replaces the old inline cropping tool, combining freeform and aspect-ratio cropping, horizontal and vertical flipping, precise rotation, and metadata editing in one place. The Media Library now defaults to infinite scrolling.

Notes that are actually usable. Notes support rich text and @ mentions, can be attached inline to specific text rather than only to a whole block, and send email notifications when you are mentioned. Shareable Revisions let you send a link to a specific revision. If you do content review with clients inside WordPress instead of in a Google Doc, this is the release where that stops being painful.

Two new blocks. Playlist, for audio tracks with optional waveforms, and Tabs, for tabbed panels. Both arrive alongside a broader accessibility pass.

Developer surface. The SVG Icon API is now public, so custom icon collections have a sanctioned home instead of inline SVGs scattered through render functions. The Abilities API gains a filterable execution lifecycle and custom validation. A new Design System brings semantic design tokens to admin interfaces.

The two things that will generate tickets

Neither is on the feature list, and both were predictable — we wrote about both before the release.

The post editor is now iframed everywhere

This is the big one. The post editor canvas is an iframe on every theme now, regardless of block API version. Until 7.1 the iframe only appeared in the Site Editor, and in WordPress 7.0 inserting a legacy v1 or v2 block turned it off entirely. That escape hatch is closed.

The breakage concentrates in custom blocks and editor plugins that assume they share a document with the admin: viewport measurements taken from the global window, click-outside listeners bound to document, editor styles enqueued through enqueue_block_editor_assets, and CSS scoped to .wp-admin. Declaring apiVersion 3 in block.json signals readiness but fixes nothing by itself.

If you have custom blocks on client sites and have not tested them yet, the iframe breakdown covers what to look for and how to test both states. Do that before you update anything with a custom block in it.

Speculative loading moved to moderate

7.1 raises the speculative loading default from conservative to moderate on sites where core detects a caching layer. More prefetching means more requests arriving at your origin from users who may never click. On a well-cached site this is fine and often a genuine win. On a site where the cache hit ratio is worse than you think, it is extra origin load you did not ask for.

This one applies whether you touch a setting or not, which is what makes it worth checking. The full write-up covers how to tune it and when to pin it back down.

A staged plan for this week

Nothing updates on its own. WordPress applies minor and security releases automatically, but major versions are opt-in — a site takes 7.1 only if somebody enabled major-version auto-updates or clicked the button. The realistic risk is not core acting unilaterally; it is a client seeing the update prompt and clicking it on a Thursday afternoon.

So the first move is not technical.

Today — send the email. Tell clients 7.1 is out, that you are rolling it out on a schedule, and to leave the update prompt alone. One email now costs less than three support tickets later.

Today — check your auto-update settings. Confirm no client site has major-version auto-updates enabled by a filter or constant that somebody set two years ago and forgot.

Day 1–2 — staging, hardest site first. Take the client site with the most custom blocks and the heaviest page builder use, clone it to staging, and update that. The worst case surfaces first, while you still have the week to deal with it. Open the post editor on a few real posts, not just a blank one — the breakage shows up in content, not in an empty canvas.

Day 2–3 — your own sites. Update your agency site and anything else you own. You are now running the version you are about to give to clients, which is worth something when they ask whether you have tried it.

Day 3–5 — the straightforward client sites. Stock themes, no custom blocks, standard plugin sets. These are usually uneventful.

Week 2 — the complicated ones. Anything with custom blocks, a heavily customised editor, or a page builder doing unusual things. By now the first 7.1.x maintenance release is on the horizon and any widespread regression has surfaced publicly.

If you tested against RC1 or RC2 during the release candidate phase, compress this. You are updating to a build you have already seen.

What to skip

Not everything in a major release needs a decision on day one.

The new blocks can wait. Playlist and Tabs are additive; nothing breaks by not using them.

The Design System and the expanded Abilities API matter if you build admin interfaces or AI-adjacent tooling, and are irrelevant otherwise. Same for the SVG Icon API — worth adopting on your next custom block, not worth a refactor sprint.

Responsive styling is the one genuinely worth scheduling time for, but as a deliberate piece of work rather than a release-week scramble. There is a real opportunity to delete custom CSS from client themes and move that styling into the editor where clients can see it. That is a project, not an update task.

The honest summary

7.1 is a solid release with two sharp edges. The features are good and mostly invisible on update day — responsive styling and the media pipeline both make things better without demanding anything from you. The iframe change is the one that turns into a support ticket, and it only affects sites with custom editor code.

If your client sites run stock themes and mainstream plugins, this update is uneventful. If you maintain custom blocks, test before you ship, because the escape hatch that saved you in 7.0 is gone.

Frequently Asked Questions

Should I update client sites to WordPress 7.1 immediately?
Not on day one, and not all at once. Major releases are opt-in, so nothing updates itself unless someone enabled major-version auto-updates. The sensible order is staging first, then your own sites, then low-risk client sites, then the complex ones with custom blocks or page builders. The exception is if you already tested against RC1 or RC2 and everything passed — then you are updating a known quantity and can move faster.
What is most likely to break in WordPress 7.1?
Custom blocks and editor plugins, because the post editor is now fully iframed on every theme. In WordPress 7.0, inserting a legacy v1 or v2 block switched the iframe off entirely; that escape hatch is gone in 7.1. Anything that reaches for the global window or document — viewport measurements, click-outside listeners, editor styles enqueued with enqueue_block_editor_assets, CSS scoped to .wp-admin — is where the breakage concentrates.
Does WordPress 7.1 change anything about site speed?
Two things. Image compression, resizing, and thumbnail generation now run in the browser via a WebAssembly build of libvips instead of on your server, which reduces PHP memory pressure and timeout risk on large uploads. Separately, 7.1 raises the speculative loading default from conservative to moderate on sites where core detects a caching layer, which increases prefetch requests hitting your origin. The second one applies whether you configure anything or not.
Who is Mary Lou?
Mary Lou Williams, the jazz pianist, arranger, and composer. WordPress major releases are named after jazz musicians. Williams began performing publicly at six, wrote across swing, bebop, and sacred jazz, and turned her Harlem apartment into a workshop where Thelonious Monk, Dizzy Gillespie, and Bud Powell worked out bebop.
Do I need to update my plugin's “Tested up to” value?
Yes, once you have actually tested against 7.1. Bumping the readme to 7.1 signals compatibility to users who are about to see update prompts on every site they own. Doing it before they ask is considerably less work than answering the same compatibility question thirty times.

Was this article helpful?