WordPress 7.1 on August 19: the practical check before you update

Structure: First the two updates and how urgent each one is. Then the three changes that carry breaking risk: iframe editor, admin lists and jQuery UI. After that the tester reports and three historical failures for context. Finally the update plan, including the details most checklists leave out.

Most articles about WordPress 7.1 talk about new blocks. They miss what happened two weeks earlier.

On August 6 the core team released WordPress 7.0.3, a security release without prior notice. It contains a cross-site scripting hole in the login screen rated critical and exploitable without being logged in. Alongside it sit a privilege escalation in multisite networks and an SSRF hole in URL validation. With an SSRF hole the server is tricked into fetching addresses on the internal network. Both are rated high.

So there are two updates on the table. They need opposite treatment. One tolerates no delay, the other can be tested calmly. Treat them the same way and you get one of them wrong.

Update one: 7.0.3 belongs on your site today

For security releases the standard advice of "test first, then go live" does not apply. Once the release is public, so is the hole, and the automated hunt for vulnerable sites begins.

The announcement puts it plainly: "Sites that support automatic background updates will begin updating shortly."

So check two things, it takes two minutes:

1. Does Tools, Site Health show the current version, meaning 7.0.3?
2. Are automatic updates for minor versions active at all? Plenty of installations switched them off at some point, often for a good reason, and never looked again.

If you are unsure about point two, that is the question worth answering first.

A case from our own work

A trade business contacted us about a broken checkout in their shop. Card payments had stopped working, and a small block of hours was meant to fix it.

We found something else. The database held 24,476 hidden spam entries, invisible to visitors and perfectly readable to Google. On top of that 375 spam posts, six injections inside real products and two unknown user accounts, one of them an administrator.

The way in was a plugin vulnerability. The shop was not broken, it had been hijacked for years. How an attack like this unfolds is described in our guide to a hacked WordPress site.

The cleanup ran in a single pass, with no loss of genuine records. The full write-up sits in our reference section, including a timeline: what we found in that shop.

The point is not the damage. The point is that nobody noticed. A deferred security update does not announce itself with an error message. It shows up years later, through a completely different symptom.

Do not assume the automatic update actually ran

For the critical hole in July, WordPress triggered forced automatic updates. That was the right call. It also creates a false sense of safety: many people consider the matter closed and never verify.

A forced update can fail silently. File permissions, time limits or a broken connection are enough. On managed hosting it sometimes runs late, or not at all.

What that looks like in practice is described first-hand by an agency in r/ProWordPress. In summary: name resolution on one server was broken, so updates never arrived. It surfaced on Monday morning. The investigation turned up new administrator accounts on three sites and a plugin that had registered its own endpoint. Access logs showed a shell script had been executed through it. The operator restored the entire server to Friday's state and rotated every credential.

Their conclusion is two sentences:

"Auto-updates are a good thing. Backups are a good thing."

Both are true. And neither replaces a look at the version actually installed.

The follow-up checks from the same post are worth copying: review the user list for unknown administrators, look for unexpected application passwords, and inspect must-use plugins and recently modified core files. We collected the groundwork in eight tips against hacking attempts.

Update two: what is actually inside WordPress 7.1

WordPress 7.1 arrives on August 19, on the final day of WordCamp US. Release candidate 1 came on August 5, RC 2 on August 6, and it contains the security fixes from 7.0.3.

The field guide gives numbers instead of slogans. More than 310 closed core tickets, over 100 enhancements, more than 180 bug fixes. The focus sits on the editor with over 40 tickets, followed by accessibility with 46, user interface with 40 and administration with 28.

Here is the honest summary: 7.1 is not a rebuild, it is a broad maintenance release.

Four changes matter for a company website:

One limitation belongs with the responsive styles. They only apply automatically to blocks that use the standard WordPress settings. Themes and plugins with custom-built blocks do not get the new controls for free.

WordPress gains an AI interface, but no AI model

This change appears in no feature list written for end users. For business customers in Germany it still raises the most questions.

With 7.1 an AI client enters the WordPress core. The field guide lists it among the included changes. The abilities API introduced in 6.9 is extended alongside it. Plugins use it to register their functions for other programs. The field guide puts it this way:

"WordPress 7.1 builds on the Abilities API introduced in WordPress 6.9, making abilities easier to discover, expose, validate, and integrate with external clients."

What matters is what does not ship with it. WordPress bundles no model and sets no default provider. It is an interface, not a service. Anyone who wants to use it supplies their own provider and their own key.

In the professional discussion on Reddit, the author of a widely commented post in r/ProWordPress summarises the state of it: without a configured provider nothing leaves the server, there is no model, no default and no keys in core. Unconfigured, the interface simply sits there.

That answers the question customers ask us first after headlines like these: no, the update does not send any content to an AI provider on its own.

Developer sentiment is mixed all the same. The most upvoted comment on that post is short and dismissive:

"If they could gut it instead, I'd be happy."

Another argues that something like this should ship as an extension rather than in core, on the grounds that 95 percent of websites do not need it. A third states the worry bluntly:

"I don't want AI on my server or in my CRM."

We do not share that position on every point, but the core of the criticism is fair: every function in core has to be maintained forever, including the ones almost nobody switches on.

A correction to a claim doing the rounds. In that same discussion and in several articles, a feature called Guidelines comes up, said to carry editorial rules and brand voice between sites. That feature is not part of 7.1. The field guide lists it among the proposals that continue to evolve and may be revisited later.

The enforced iframe editor: the change with the greatest breaking risk

Documentation for it sits in a developer note, not in the feature lists.

An iframe is an isolated frame inside the browser.

Aki Hamano writes in the dev note of August 3:

"Starting in WordPress 7.1, the post editor is always iframed, regardless of the theme type, the block API versions of the registered blocks, or the block API versions of the blocks in the content."

The decisive phrase is "regardless of". Up to 7.0 the iframe came with conditions. If every block used the modern API version, the editor was framed, otherwise it was not.

That removes the old escape route. Anyone who left their plugin on an older block version was previously unaffected. In 7.1 that no longer protects anything, it only breaks.

The technical reason sits in the same note:

"the iframe has its own document and window, separate from the admin page where editor scripts run."

Scripts that reach into editor elements from the outside now reach into nothing.

A reproduced failure from testing

What that looks like is shown by Gutenberg issue 80119, filed on July 10.

A tester reproduces a JavaScript failure on a 7.1 pre-release with PHP 8.3 when inserting certain blocks. A core developer names the cause. The editor switched between both modes when a block with an older API version was inserted. That left an orphaned element behind.

The notable part: 7.1 removes precisely this failure mode, because the switch disappears. So the change fixes one problem. At the same time it creates a new one for everyone who never made the move.

Developer sentiment around it is not negative. The dev note carries a single reaction, and it is positive. Fabian Kaegy writes on August 3:

"Big kudos to everyone that has been working on this for the last several years. I know it's been a painful path with lots of setbacks. But I'm so glad we finally made it."

The iframe is not a defect, it is the end of a rebuild that took years. It only hits plugins that never came along.

How to check whether this affects you

Open a post in the editor and press F12 for your browser's developer tools. Search the elements tab for iframe[name="editor-canvas"].

If you find it, your editor already runs framed. That part is behind you.

Ryan Welcher provides ready-made test environments at iframe-editor-examples. They let you compare the old and the new behaviour side by side in two browser tabs, with nothing to install.

For custom blocks there are official migration patterns. They sit in the handbook on iframe compatibility.

If that turns up several older plugins with custom editor fields: those are exactly the cases we take apart before the update as part of WordPress maintenance.

The quiet second breaking point: markup in the admin lists

This change appears in no preview because it is invisible.

In the list views for posts and pages the table structure changes. The column holding the checkbox switches its HTML element, and so does the title column. The trigger is an eleven-year-old accessibility ticket.

Roger Montti describes the consequence on August 6 in Search Engine Journal:

"Plugins that use CSS or JavaScript to target specific <th> or <td> elements in WordPress admin post list tables are the ones at risk."

So the plugins at risk are the ones that add their own columns to these lists and target the previous structure. The same article carries reassurance for the widely used SEO plugins: Yoast SEO, Rank Math and All in One SEO are considered safe.

In practice that means: if a column in the post overview shifts or stays empty after the update, this is the likely cause. The front end is not affected.

jQuery UI moves to 1.14.2

jQuery UI is a bundled code library for interface elements such as date pickers or drag and drop. The announcement of July 29 explicitly flags the need to test plugins built on it.

The ones affected are typically older form, booking and calendar plugins. Which is to say exactly the areas your enquiries come through. A date field that no longer opens often goes unnoticed for days. If you would rather hand that check over permanently, the terms are on WordPress maintenance from 9.90 euros a month.

Three features that did not make it into 7.1

The field guide carries a section of its own titled "What changes didn't make the 7.1 release". Plan from the beta announcement instead and you plan around features that will not ship.

Real-time collaboration is not coming. The field guide says:

"Real-time collaborative editing received extensive testing and feedback during the WordPress 7.1 cycle, but it is not enabled in the final release."

The reasoning comes from the previous cycle. In May the feature was already pulled from 7.0, twelve days before launch. The core team named:

"concerns around surface area, race conditions, server load, memory efficiency, and recurring bugs found through fuzz testing"

Anyone who planned collaborative editing for an editorial team has now been planning around it for two releases.

The "On This Day" widget is out. The beta 1 announcement of July 15 still lists it as a new feature. It has moved to 7.2. Anyone using that announcement as a planning basis is working from an outdated picture.

The Classic block stays. The story behind it rewards a closer look.

The roadmap of June 19 announced the removal of the Classic block from the inserter. The change landed in the code as well. On July 6 it was reverted through pull request 79894, titled "Classic block: Remove migration notice and restore inserter availability".

A day later the core team explained the reversal publicly, in unusually candid terms:

"This approach had things largely backward. It's one step that makes the experience worse with no direct gain."

In short: the Classic block should become redundant by choice, not by force. The corresponding switch in the code never shipped in a release.

For businesses still maintaining content in the Classic block, nothing changes. No migration is required.

And one piece of misinformation that keeps circulating. Several secondary sources write that 7.1 is built on a move to React 19, the technology behind the editor interface. The field guide contradicts that:

"The React 19 upgrade was also deferred beyond WordPress 7.1 and continues as an experiment in the Gutenberg plugin."

What testers are actually reporting in the release candidate

Three themes come up repeatedly.

Meta boxes are the real pain point

Meta boxes are the additional fields below the editor where many plugins put their settings. With 7.0 they moved into a new split layout. With the enforced iframe in 7.1, everyone will see it.

The corresponding bug report 79127 has been open since June 11. One user writes on July 15:

"If you never manually drag the meta boxes section, but simply click it to open it, it will have a height of auto and fill the entire screen. This is the default state I often see when opening a post / page to edit, making it look like the entire editor is missing. The way you can't simply scroll down to see meta boxes anymore is extremely frustrating."

Another describes a scrolling problem on August 5:

"When I am at the bottom of a post and open the meta-box pane, then try to return to the post content, the editor jumps all the way back to the H1 instead of preserving my scroll position."

On top of that comes a naming problem. The panel is labelled "Meta Boxes". A further report says editors have no idea what to make of that. The term never appeared in the earlier interfaces.

For editorial teams this is the most relevant point of the whole release. Not because something breaks, but because the way of working changes and questions follow.

Testers report open issues with responsive styling

Responsive styling is the change editors will notice first. In a forum thread a tester describes two usability problems in July. First, the dropdown uses the same checkmark for two different meanings. Second, you cannot tell from a block whether separate settings for tablet or mobile have been stored.

A second tester replies briefly:

"I'd agree this doesn't feel ready to ship."

The reporter continued the discussion on August 5 as issue 81226. There he argues from the perspective of a university network with several thousand sites:

"The editors are usually not developers or experienced web creators, so any added editor complexity lands on a central support team at scale. A small point of confusion becomes many tickets, not one."

That is the sentence we recognise from client projects. A feature that is obvious to developers produces twenty questions from twenty editors.

A core developer reports a display problem too

Andy Fragen is a core committer himself. In the forum thread Styling error in latest nightly he reports a missing control in the list views. Another user confirms the finding and describes the plugin overview as rendering incorrectly.

Observations like these are normal during testing and are usually fixed before release. They do show that the list views were touched in several places during this cycle.

What we explicitly did not find

As of today there is no public statement from Yoast, Advanced Custom Fields, WooCommerce or Elementor about an incompatibility with 7.1. Those names appear in bug reports only as environment details, not as confirmed failures.

Anyone writing that the major plugins will break has no evidence for it right now. So we do not write it.

What earlier major updates taught us

The question of whether an update can genuinely wreck a site is not one to answer by instinct. There are documented cases. Three of them are instructive.

WordPress 6.4 and the correction two days later. Version 6.4 shipped on November 7, 2023, version 6.4.1 on November 9. The official version page states: "WordPress 6.4.1 fixes 4 regressions introduced in version 6.4."

Two of them stand out. Core removed a property it no longer needed itself, while third-party plugins kept reading it. The result was hard failures. And an updated network library broke on servers with older system components, which made updates to core, plugins and themes fail. A third ticket is titled "Categories are removed when bulk editing posts", meaning silent data loss.

WordPress 6.2.1 and the shortcodes. In May 2023 a security fix removed shortcode processing in block templates entirely. Every site with shortcodes in a template broke, rolled out through automatic updates with no warning. The correction followed four days later.

An affected developer is quoted at WPTavern:

"This update has been nothing short of a disaster. I cannot understand how there was no warning of such a destructive, automatic roll out!"

WordPress 5.5 and jQuery Migrate. In August 2020 core stopped shipping a compatibility layer for older JavaScript. Sliders, forms and admin screens quietly stopped working. The core team pushed out a helper plugin. According to WPTavern it passed 10,000 active installations within a week.

And the most recent case

WordPress 7.0 shipped on May 20, 2026. Seven weeks later WordPress 7.0.1 arrived with 31 bug fixes. Among them a fault that destroyed valid CSS for background images on save. That one shows up directly in the front end.

From this follows the realistic expectation: a major update runs cleanly for the large majority. And every time there is a minority for whom it does not.

Which group a given site belongs to is decided by its plugins, not by chance.

The update plan for August 19

Order matters more than thoroughness.

The basic steps

1. Install 7.0.3, immediately. That is the security part and it does not belong in a test loop.
2. Take a backup and settle the way back. Save database and files, check whether your host offers a restore point.
3. Test 7.1 on a copy, not live. A staging environment is a test copy of your site. Many hosts create one at the click of a button.
4. Click through four areas. Home page, a service page, a form, a post using the Classic block. Do all fields appear, does everything save?
5. Check forms and bookings first. They rely on jQuery UI most often and they are business critical.
6. Skim the plugin changelogs. If a vendor names 7.1 or the iframe editor explicitly, that is a good sign.

The details most checklists leave out

These points come from the developer documentation and from what has cost us time in projects.

Do not switch off automatic updates wholesale. The WP_AUTO_UPDATE_CORE setting knows three values: everything, nothing, or minor versions only. The middle option is almost always right. Security patches arrive on their own, the major version waits for your date. Switch everything off and the security patches stop arriving too. And you will not notice.

The release candidate is the real deadline, not August 19. After the first release candidate only bug fixes land in the code. Test on release day and you are too late to report anything.

The pre-release can be installed deliberately. With WP-CLI, wp core update --version=7.1-RC2 is enough. The exact label of the current pre-release is named in its announcement. That way you test today what ships on August 19.

The browser sandbox saves you half a test environment. The official WordPress Playground lets you assemble a pre-release, a PHP version and a specific plugin straight from the address bar, with nothing to install. For the question of whether one particular plugin survives 7.1, that is often enough.

Custom blocks can be checked mechanically. The official Plugin Check tool now reports when a block is not yet on the API version the iframe editor requires.

A rollback is not an undo. Reverting swaps the program files but not the state of the database. If the database already runs on the new schema, symptoms appear that nobody attributes correctly: the admin loads, the editor does not. The front end looks normal, the API answers with a server error. The clean way back is always the backup taken beforehand, files and database together.

For the worst case there is the Core Rollback plugin by Andy Fragen, a core committer. It carries an honest warning in its own text: rolling back core can leave a site unusable.

The opcode cache produces errors that look like plugin errors. WordPress clears it during updates, but not completely, and some hosts opt out of that mechanism. A stale cache after a core update produces failures that look like plugin bugs. If something inexplicable happens right after an update, that is the first suspect.

On multisite the database adjustment does not run for every site by itself. It has to be triggered for the network, and it can be checked in a dry run beforehand.

Compare scheduled tasks before and after. A list of scheduled events before the update and after it shows immediately whether something got lost. Missing entries later explain newsletters that do not go out, or backups that do not run.

If an admin page hangs after the update, check outbound connections first. When a back-end page hangs without an error message, a plugin is often waiting on an outbound request. The server drops it silently, so the plugin waits until it times out. The line define('WP_HTTP_BLOCK_EXTERNAL', true); in wp-config.php settles that in a minute. If the page then loads instantly, you have your direction. This was discussed in r/Wordpress around a case on 7.0.3.

The same thread carries a second useful narrowing step. If the same page loads instantly with &noheader=1 appended, the problem sits in the construction of the admin header. In that case the page itself is not at fault.

In fairness: in that same discussion a user reports random server errors on roughly four percent of requests after updating to 7.0.3. No cause was found there, and it is a single report. We mention it because it shows why even a security update deserves a short check afterwards.

The test copy has to genuinely match production. Pantheon puts it this way:

"The number one cause of 'it worked on staging but broke in production' is environmental mismatch."

What is meant is an identical PHP version including extensions, the same database configuration and the same caching layers. Making it worse, some hosts deliberately activate a different plugin set on the test copy. Then you are testing exactly the thing that does not matter.

After every update we also check the error logs in the first few minutes. Then we verify that every previously active plugin is still active. A failed update disables plugins silently.

Who should update and who can wait

If you run a current block theme, well-maintained plugins and a small plugin footprint, you can update soon. The benefit sits in the 180-plus bug fixes and the 46 accessibility tickets, not in the new blocks.

If you have been considering a fundamental theme rebuild anyway, a release like this is the moment. What a WordPress relaunch without a page builder looks like is on the service page.

If you run many older plugins with custom editor fields, wait one or two weeks. Most vendors ship their adjustments in that window. That is not hesitation, that is sequence.

If you have an editorial team, plan the date independently of the technology. The split meta box layout visibly changes how people work. A short heads-up to the editors beforehand saves more time than the test costs.

What we see in projects again and again: the damage rarely comes from the update. It comes from the update without a test copy and without a backup, on a Friday afternoon. A break then only surfaces when an enquiry fails to arrive. And by then nobody knows since when.

Here is what the good outcome looks like: on August 19 the update goes through, the forms keep taking enquiries, and nobody on the team notices a thing. That takes no luck, just a test copy and an hour beforehand.

How the previous jump went is covered in our take on the update to 7.0. And the critical hole from July shows how tight the cycles have become. If you are weighing up whether WordPress remains the right system at all, our comparison of WordPress and TYPO3 covers it.

If you would rather not run this yourself: we take on maintenance and updates including monitoring. We review existing installations for WordPress security. How we work with WordPress in general is on our WordPress services page.

About the sources for this article

How we work: every number and every quotation goes back to a primary source we retrieved ourselves on the date given. Statements from forums count as a lead, not as evidence, and are verified before we use them. What cannot be substantiated does not enter the text, even when it would make the story better. Two claims dropped out during this check.

This article was produced with AI assistance during research and drafting. Facts, quotations and judgement come from verified sources and our own project experience, and responsibility for the text rests with the author.

We reviewed the official primary sources: field guide, developer notes and release announcements. Added to those were the WordPress.org support forums from the alpha and beta area and the bug reports in the Gutenberg project on GitHub. Every quotation appears with author, date and location in the source list.

Three discussions from the r/Wordpress and r/ProWordPress communities are included as well. They are linked by name. Posts there are written under pseudonyms. That is why we verify every statement from them against a primary source before we use it.

Hacker News has nothing on WordPress 7.1.

We looked for public accounts from hosts or other service providers about concrete update failures and found none. That is a genuine gap in the literature.

• WordPress News, WordPress 7.0.3 Security Release. wordpress.org
• Make WordPress Core, WordPress 7.1 Field Guide. make.wordpress.org
• Make WordPress Core, Iframed editor changes in WordPress 7.1, dev note by Aki Hamano. make.wordpress.org
• Make WordPress Core, jQuery UI updated to 1.14.2 in WordPress 7.1. make.wordpress.org
• Make WordPress Core, The Classic block stays in the inserter for WordPress 7.1. make.wordpress.org
• Make WordPress Core, Real-time collaboration will not ship in WordPress 7.0. make.wordpress.org
• GitHub, Gutenberg PR 79894, Classic block: Remove migration notice and restore inserter availability. github.com
• GitHub, Gutenberg Issue 80119, TypeError in getComputedStyle on 7.1-alpha. github.com
• GitHub, Gutenberg Issue 79127, WP 7.0 regression: meta boxes cover the full editor. github.com
• GitHub, Gutenberg Issue 81226, feedback on responsive styling from a university multisite. github.com
• WordPress support forum, Responsive styling 7.1: useful feature but a few UI things confused me. wordpress.org
• WordPress support forum, Styling error in latest nightly. wordpress.org
• Search Engine Journal, WordPress 7.1 Accessibility Change May Break Some Plugins, Roger Montti. searchenginejournal.com
• WordPress.org, version 6.4.1. wordpress.org
• WPTavern, WordPress 6.2.1 Update Breaks Shortcode Support in Block Templates. wptavern.com
• WPTavern, Enable jQuery Migrate Helper Plugin Passes 10K Active Installs. wptavern.com
• WordPress News, WordPress 7.0.1 Maintenance Release. wordpress.org
• WordPress Developer Resources, Upgrading WordPress. developer.wordpress.org
• WordPress Developer Resources, Block migration for iframe editor compatibility. developer.wordpress.org
• GitHub, Ryan Welcher, iframe-editor-examples. github.com
• WordPress.org plugin directory, Plugin Check. wordpress.org
• WordPress.org plugin directory, Core Rollback by Andy Fragen. wordpress.org
• WordPress Developer Resources, wp_opcache_invalidate. developer.wordpress.org
• Pantheon Learning Center, Staging to Production. pantheon.io
• Reddit r/ProWordPress, WordPress 7.1 ships an AI Client with no model and no default provider. reddit.com
• Reddit r/ProWordPress, If you are running 6.9 or 7.0, WordPress forced-updated you, but check anyway. reddit.com
• Reddit r/Wordpress, Admin plugin page stuck loading on WP 7.0.3. reddit.com