WordPress 7.1 was released on 19 August 2026. That is not a reason to update every production site immediately, and it is not a reason to postpone the update indefinitely. It is a trigger for a controlled upgrade: understand the change, inventory the site, test a matching copy, and release with a verified backup and rollback decision.
WordPress.org records 7.1 under the name Mary Lou. The developer overview highlights changes that reach beyond visual polish: responsive styles in Core, pseudo states, the SVG Icon API, Abilities API updates, and a post editor that always runs inside an iframe.
Official WordPress version record and August developer overview
What site owners should notice
Responsive styles can define tablet and mobile values in Global Styles or on an individual block. This can remove some custom CSS, but it does not repair old CSS or a third-party builder automatically. Default styles continue unless overridden, and themes can configure their own breakpoints.
Notes and collaboration improvements make editorial review clearer, while blocks such as Playlist add content options. Do not assume every roadmap item reached the final release. The developer overview notes that React 19 and full real-time collaboration did not ship in 7.1.
What theme and plugin developers should inspect
The largest compatibility surface is the always-iframed post editor. An editor extension that inherits admin-page CSS or reaches outside the editing canvas may now behave differently. Older blocks using Block API v2 or below should be reviewed and moved to v3 where required.
The release also expands the Abilities API, custom icon registration, admin components, and Site Editor extension points. Those capabilities can be useful, but they are not a reason to refactor working production code blindly. Read the field guide and the dev note for the subsystem you use, then add a test for the behavior that may change.
Security comes before feature excitement
Several maintenance and security releases preceded 7.1 across supported branches. If a site is behind, changing only the Core number is not enough. Inventory PHP, the database, theme, plugins, cache, WAF, and any files changed outside the deployment process. Find out whether previous automatic updates failed.
An important security update should not sit on an exposed production server while a team debates indefinitely. The safer answer is to keep a ready staging environment, repeatable smoke tests, and a named rollback owner so the risk window stays short.
Before the upgrade
- Record WordPress, PHP, MariaDB or MySQL, theme, and active plugin versions.
- Review vendor compatibility for commercial plugins, especially cache, SEO, builders, payments, and security.
- Back up the database,
wp-content, and configuration outside the server. - Prove that the backup can be read and restored.
- Build staging from representative data, sanitizing sensitive information where necessary.
- Enable logging in staging without exposing errors to visitors.
- Define acceptance routes before clicking Update.
Test the work, not only the homepage
Start with the paths that deliver value or collect money:
- home, menus, search, and every supported language;
- create, edit, preview, and publish with each custom block;
- forms, outbound mail, and real receipt at the destination;
- login, password reset, and roles;
- WooCommerce cart, checkout, tax, stock, and webhooks;
- cache behavior for anonymous and signed-in users;
- REST API, cron, scheduled work, and connected mobile clients;
- mobile, tablet, desktop, keyboard, and screen reader behavior.
Inside the editor, open sidebars, dialogs, and custom blocks. Check browser console, PHP logs, and network failures. A working public page does not prove that the content team can edit it tomorrow.
Release with a rollback path
Freeze editing for a short window or record changes that must be replayed. Take a final backup, then update Core and extensions in the order proven on staging. Clear caches deliberately, run the same smoke tests, and watch logs, payment callbacks, and email.
The rollback plan should answer in advance whether it restores files, database, or both. What happens to orders or comments created after release? Who can change cache or DNS if needed? Restoring an old database may delete new business records, so the decision window must be short and monitored.
Business cost of upgrading
Upgrade cost is not the time spent pressing buttons. It includes dependency inventory, staging, compatibility work, testing, and observation. A small brochure site may need a short path. A store or membership platform needs a state matrix and payment tests in a sandbox.
Delaying upgrades compounds security and technical debt. Updating without tests can stop sales or publishing. The economical approach is a small repeatable process after each release rather than a rescue project every two years.
Keep a compatibility ledger for the theme, critical plugins, PHP version, cache layer, mail provider, and payment gateway. Record the vendor statement separately from your staging result and name the owner of each release decision. After deployment, compare PHP and JavaScript errors, scheduled-task failures, email receipt, checkout conversion, and support tickets with the pre-upgrade baseline. This turns a vague compatibility claim into evidence the team can use for rollback or the next maintenance window.
My recommendation
I would move to WordPress 7.1 after a matching staging pass, not treat the version number as proof. On sites with custom blocks, a builder, or WooCommerce, I would prioritize editor, checkout, and cache behavior before cosmetic detail. If a critical test fails, fix the cause or delay with an explicit protection plan instead of hiding the failure.
The release is also an opportunity to improve maintenance itself: restorable backups, known tests, a change log, and one accountable release owner.
Sources and review date
- WordPress Versions
- What’s new for developers, August 2026
- WordPress 7.1 Field Guide
- Release status was reviewed on 22 August 2026.