WordPress 7.1 “Mary Lou” shipped on 19 August 2026. It is not just another block-editor changelog. It changes how you style layouts, review content, and process media. Below: what actually changed versus 7.0, what the 7.0.2–7.0.4 security releases mean, and how to decide on a production upgrade instead of a conference slide.

Release context

7.1 is the second major 2026 release after WordPress 7.0 in May. Read the official announcement and the Field Guide before you touch production, especially if you maintain custom blocks, meta boxes, or editor skins.

If the server is still on 7.0.0 or 7.0.1, this is not a feature conversation. Patch security first, then talk about 7.1.

What actually landed in 7.1

Responsive styles without custom CSS

The Site Editor can style a block for desktop, tablet, and mobile — in Global Styles and per block. Block themes override breakpoints in theme.json. That closes the gap we used to fill with child-theme media queries.

In practice you get fewer “works at 1440px” layouts. You also get more ways for an editor to break a layout by nudging a breakpoint. On staging, test three widths, not one.

Button hover / focus / active

The Button block now has distinct interactive styles in the sidebar. Good for focus visibility. Bad if theme and plugin buttons start fighting. Check CTAs, checkout, and forms first — that is where a “small core change” shows up in production.

Media editor and client-side processing

Inline crop is now a modal: freeform and aspect-ratio crop, flip, rotation, metadata. Compression, resize, and thumbnails can run in the browser — fewer PHP timeouts and fewer memory-limit crashes on iPhone HEIC files.

7.1 adds native AVIF, HEIC, and HDR gain maps. Hosts with aggressive Imagick/Ghostscript still need a look — see 7.0.4 below.

Notes: mentions, rich text, selections

Notes become a review tool: formatting, links, @mention with email, notes on a text selection, multiple threads on one block. On a company site with several editors this is a real workflow change. On a one-admin brochure site it is noise.

Admin bar in every editor

The bar stays visible in the post editor and the Site Editor. Custom CSS that hid it will show up immediately.

New blocks: Tabs, Playlist, icons

Tabs and Playlist ship in core. The SVG Icon API is public: wp_register_icon_collection(), wp_register_icon(). Before you add a third tabs plugin, check whether core Tabs is enough — fewer dependencies, smaller attack surface.

Versus WordPress 7.0

7.0 was the platform shift (FSE, collaborative editing, design tokens). 7.1 is operational: how you style, review, and ingest media. The developer-facing change that matters: the post editor is fully iframed, including sites with legacy meta boxes. A plugin that reached into the editor document or injected admin CSS blindly can break.

Block CSS may emit only when the block is on the page. Headless setups that assumed global Cover Block CSS can get unstyled HTML. If WordPress is “just” a CMS for Next.js, you still test this on staging.

Security: 7.0.2, 7.0.3, 7.0.4

Before anyone asks whether 7.1 is “stable”, ask whether core is patched. Summer 2026 was not quiet.

7.0.2 (July): SQL injection plus REST batch route confusion → unauthenticated RCE on 6.9–7.0.1 (CVE-2026-60137, CVE-2026-63030). WordPress.org enabled forced auto-updates. Backports: 6.9.5, 6.8.6 (SQLi only).
7.0.3 (August): including pre-auth login-screen XSS with a path to PHP execution, plus XSS/SSRF/filter bypasses. Fixes also landed in 7.1 RC2.
7.0.4: Author+ RCE via a malicious upload on Imagick + Ghostscript stacks (CVE-2026-65640). Backported into 7.1 RC3.

7.1 includes those fixes. Staying on 7.0.0 “because plugin X dislikes minors” is a risk decision, not caution. Broader context: the WordPress security checklist and a security audit.

Preparing a production site

You do not update “core in isolation”. The sequence I use:

Inventory: PHP (supported by 7.1), memory limit, plugins/themes with last-update dates, mu-plugins, drop-ins.
Read the Field Guide for the iframed editor, Abilities API, and theme.json — not the entire Gutenberg changelog.
Staging with a real copy of files and the database.
A backup you can restore — see WordPress backups. Files + DB + off-site. Test restore on a separate URL.
Update plugins and the theme on staging before core, then core to 7.1, then smoke tests.

Plugins and theme

Highest risk: editor (ACF, classic meta boxes, page builders), media (optimizers, CDN, watermarks), security (WAF, 2FA, hidden login), cache. A page builder that injects styles into the editor window is the first iframe casualty.

Staging sequence (WP-CLI)

wp db export /backups/pre-71-$(date +%F).sql
wp plugin update --all
wp theme update --all
wp core update --version=7.1
wp core verify-checksums
wp cache flush
wp rewrite flush

Then by hand: login, edit an ACF page, upload HEIC, checkout if Woo. If it breaks, restore SQL + files — do not “fix it in production”. Block-theme breakpoints in 7.1 look roughly like this — make sure a child theme is not overriding them blindly:

{
  "settings": {
    "custom": {
      "breakpoints": {
        "mobile": "480px",
        "tablet": "782px"
      }
    }
  }
}

The Abilities API (from 6.9) gains execution-lifecycle filters and a public-exposure flag in 7.1. If you ship “AI in wp-admin” plugins, read those Field Guide notes before you expose an ability over REST.

What to test after the upgrade

Login, 2FA, password reset (the 7.0.3 login XSS was not theoretical).
Post/page editing: meta boxes, ACF, preview, Notes if the team uses them.
HEIC/JPEG upload, thumbnail regen, CDN.
Front: menus, forms, WooCommerce checkout, cache purge.
REST and GraphQL if you are headless — Next.js + headless WordPress.
Three breakpoints on a page that uses the new responsive styles.

Upgrade immediately when

You are on 7.0.0–7.0.3 — get to 7.0.4 or 7.1; do not sit on a known hole.
Staging passed editor, checkout, and upload.
You do not inject custom JS into the editor document.
You have a backup and a rollback window.

Wait a few days when

You ship a custom editor plugin that walks the DOM outside the iframe.
WooCommerce with a heavily forked checkout — wait for vendor compatibility notes, but still patch security.
Headless HTML that assumed global block CSS.
You have no staging. Then you do not “wait for 7.1.1” — you build staging.

FAQ

Does 7.1 require PHP 8.3?

Follow the official 7.1 matrix on WordPress.org. Do not guess from forum threads.

Are core auto-updates acceptable?

For security minors, yes, if you can roll back. For 7.0 → 7.1 on a custom checkout, no. Split security minors from editor-facing releases.

Do core Tabs replace a tabs plugin?

On simple landings, yes. On complex accordion/SEO markup, measure before you uninstall. Fewer plugins is a smaller attack surface, not a religion.

Summary

Take WordPress 7.1 because it closes a rough security summer and gives editors tools they will actually use. Ship it through staging, backup, and an editor test — not “Update Now” on a Friday production box. If WordPress is only a CMS behind Next.js, 7.1 still matters for REST/GraphQL, the iframe, and block CSS. The rest is process, not a version number.