WordPress 7.1: What Changed and Whether to Update Now

WordPress 7.1, named "Mary Lou", was released on August 19, 2026. Two follow-up releases arrived within five weeks: 7.1.1 on September 17 and 7.1.2 on September 22. The second one fixes a critical security vulnerability, so "should I update?" has two different answers depending on where your site is today.

If the site already runs 7.1, install 7.1.2 now. If it is still on 7.0 or older, the move is a feature update with four changes that can break plugins and custom code, and it deserves an afternoon on staging. Here is what changed, what to test and in which order.

Where your site stands today

Your site runs	What to do
7.1 or 7.1.1	Apply 7.1.2, or whichever 7.1.x is newest, straight away. Security releases are built to install without a staging pass.
7.0.x	Confirm the newest 7.0 security release is installed, then plan the 7.1 update with a staging test.
6.9 or older	The same, and check the PHP version first. Anything below PHP 7.4 cannot run 7.0 or 7.1.
Any version, with custom blocks, old meta boxes or plugins nobody maintains	Test the editor on staging before anything else.

Minor releases install themselves by default, so most 7.1 sites already run 7.1.2. Check under Dashboard > Updates to be sure. The security fixes were also backported to older branches, as far back as 4.7. The project calls that a courtesy: only the most recent version is actively supported. A backport buys time to plan the move. It does not replace it.

What editors and content teams will notice

The WordPress 7.1 release announcement has the full list. These are the changes daily users of the admin meet first.

Responsive styles and new blocks

A block can now look different on a phone and on a tablet without custom CSS. Switch on "Responsive styles" in the editor's View menu, or use the viewport states in Global Styles. Block themes can set their own breakpoints under settings.viewport in theme.json. Button blocks also get separate styles for hover, focus and active states. Two blocks are new: Tabs, for tabbed panels of content, and Playlist, for a set of audio tracks.

A new image editor and browser-side processing

Cropping moves out of the block and into a media editor window with freeform and fixed-ratio crops, flipping, rotation and metadata fields in one place. Images uploaded in the block editor can be compressed and resized in the browser before they reach the server, with support for AVIF, HEIC and HDR gain maps. A HEIC photo from a phone is converted to JPEG before upload, even when the host has no HEIC support. The Media Library grid now scrolls continuously by default. Anyone who prefers the old "Load more" button can restore it under Users > Profile.

The toolbar follows you into the editor

The admin toolbar stays visible inside the post editor and the Site Editor. The "W" logo or site icon that used to take you back to the dashboard is replaced by a back arrow. Distraction Free mode still hides the toolbar. Warn your editors before the update.

Notes, the block comments used for editorial review, now accept bold, italic, code and links, let you mention a colleague with @, and can be attached to a piece of text and not only to a whole block.

Four changes that can break plugins and custom code

These come from the developer notes collected in the WordPress 7.1 Field Guide. Each is harmless on a site with current, maintained plugins and a real risk on one with older custom work.

The post editor always runs inside an iframe

In 7.0 the post editor was iframed only when every block in the content used block API version 3 or higher. From 7.1 it is always iframed, whatever the theme and whatever the blocks, including on sites that register classic meta boxes. Code that reaches the editing canvas through the global document or window now looks at the wrong document. The symptoms are a custom block whose script never starts in the editor, styles missing from the canvas, or a plugin button that cannot find the selected text. The developer-side fix is to work from the block element's ownerDocument and defaultView.

jQuery UI moves from 1.13.3 to 1.14.2

The new version drops Internet Explorer and legacy Edge and removes four internal helpers: $.ui.ie, $.ui.safeActiveElement, $.ui.safeBlur and $.fn._form. Core keeps a backward-compatibility flag switched on, so most plugins carry on working. Check older plugins with date pickers, drag-to-sort lists, dialogs and tabbed settings screens: booking calendars, form builders, anything last updated years ago.

Uploads are processed in the browser where it can do the job

In Chromium-based browsers on a capable device, the block editor creates every image size locally and uploads them one by one. Firefox and Safari fall back to server processing with no visible difference. Image optimization, watermark and offloading plugins that hook wp_generate_attachment_metadata see that hook fire twice for one upload, once on create and once on update, and must cope with both passes. The editor also sends an isolation header that can affect third-party embeds inside the editor. If either causes trouble, switch the feature off in a must-use plugin and uploads go back to the server:

add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );

A comment notification filter changed meaning

The notify_post_author filter now has the final say on whether a post author is emailed about a comment. A site that forces it to true with __return_true will start emailing authors about comments that are still held for moderation, spam included. Search the theme's functions.php and your custom plugins for the filter name.

One visual change belongs here too. The Navigation block no longer pushes its font size down to nested menu items, so check submenus on staging for text that changed size.

PHP and database requirements are the same as 7.0

WordPress 7.1 runs on PHP 7.4 through 8.5. The minimum did not move in this release: it went up in 7.0, which dropped PHP 7.2 and 7.3, and sites on those two versions stay on the 6.9 branch until PHP is upgraded. The WordPress requirements page recommends PHP 8.3 or greater with MariaDB 10.11 or MySQL 8.0 or greater.

Read your versions at Tools > Site Health > Info > Server. If the site is on PHP 8.1 or older, that branch no longer receives security fixes from the PHP project. Do the PHP upgrade as its own job, before or after the core update and never in the same sitting, so a failure has one possible cause. We describe that job in upgrading PHP on a WordPress site.

What did not ship in 7.1

Real-time collaborative editing was tested widely during the cycle and is not enabled in the final release, so do not plan an editorial workflow around it yet. A proposal to hide the Classic block from the inserter was reverted, and the block remains available for new and existing content. The editor's move to React 19 was postponed to a later release.

A staging test plan for this update

1. Copy the live site to staging on the same PHP version.
2. Update plugins and the theme first, and read the changelogs of the important ones for notes about 7.1.
3. Update core to the newest 7.1.x and let the database update finish.
4. Editor. Open and save one entry of every post type: posts, pages, products, courses, any custom type. Keep the browser console open and check every plugin panel and meta box.
5. Media. In Chrome, upload a JPEG, a PNG and a phone photo from the block editor. Confirm that all image sizes exist and that your optimization or offloading plugin handled them. Crop one image in the new editor.
6. Front end. Menus with submenus, buttons, and any tabs or sliders, on a phone and on a desktop.
7. Old plugin screens. Date pickers, drag-and-drop ordering, settings tabs.
8. The paths that earn money. A checkout with a test payment, an enrollment, every form, login and password reset.
9. The log. Read wp-content/debug.log for new warnings.

When staging is clean, repeat the same order on the live site in a quiet hour with a fresh backup. Our pre-update checklist covers the backup and rollback side.

Who should run this update

A site on a maintained theme with well-known, current plugins can go through the plan above without a developer. Bring one in when the site has custom blocks or meta boxes written years ago, when it relies on plugins their authors have stopped updating, when an editor or upload failure would stop a store or a course team from working, or when the server is stuck on PHP 7.2 or 7.3. In those cases the update is mostly testing and repair, which is what a WordPress maintenance service is for. If the test turns up a custom block that no longer loads in the editor, the lasting fix is a proper update of that code by a WordPress plugin developer.

Frequently asked questions

Is WordPress 7.1 stable enough to install now?

Yes. It has had two follow-up releases, so install the newest 7.1.x and not 7.1.0. It is still a feature update: on a site with custom code, a store or an LMS, run it on staging first.

Do I have to upgrade PHP before installing WordPress 7.1?

Only if the server runs a PHP version below 7.4, which is the minimum since 7.0. WordPress.org recommends PHP 8.3 or greater, and 7.1 supports every branch up to 8.5.

Does WordPress 7.1 include real-time collaborative editing?

No. It was tested during the release cycle but is not enabled in 7.1. Notes did improve, with formatting, mentions and comments on selected text.

Can I turn off browser-side image processing?

Yes. Return false from the wp_client_side_media_processing_enabled filter in a must-use plugin. Uploads are then processed on the server as they were before.