WordPress 7.1 Broke My Site: Known Issues and Fixes

Your site updated to WordPress 7.1 “Mary Lou”, released on 19 August 2026, and now something is wrong: “There has been a critical error on this website”, a plugin’s screen that will not open, editor tools behaving strangely, or images that upload differently. The timing makes the update the obvious suspect, and sometimes it really is the cause.

A major release changes thousands of lines of code. Most breakage after one comes from a plugin or theme that relied on behavior core changed, and a smaller share comes from genuine core bugs that the next point release fixes. This guide lists the 7.1 changes most likely to break sites, based on the official WordPress 7.1 Field Guide and developer notes, the known 7.1 problems that 7.1.1 fixed, how to prove whether 7.1 caused your problem, how to roll back without making things worse, and how to report a bug properly.

What is happening

WordPress versions are numbered MAJOR.MINOR.PATCH in practice: 7.1 is a major feature release, and 7.1.1, 7.1.2 and so on are maintenance and security releases on the same branch. By the time you read this, 7.1 has had several point releases. As of early November 2026 the newest is 7.1.4, released on 28 October 2026. Every point release since 7.1.1 has included security fixes, so staying on plain 7.1 is the worst of both worlds.

Release	Date	What it contained
7.1	19 August 2026	Feature release
7.1.1	17 September 2026	Bug fixes for 7.1 regressions (17 core, 19 block editor) plus 11 security fixes
7.1.2	22 September 2026	One critical security fix in page template resolution
7.1.3	6 October 2026	7 security fixes and 4 bug fixes
7.1.4	28 October 2026	Multiple security fixes, including the upgrade process and an update to the bundled root certificates

Before you start

You need administrator access to WordPress and either SSH or your host’s control panel (for the error log and File Manager). Take a fresh backup of files and database before you change anything. If the dashboard is unreachable, our critical error guide shows how to use recovery mode and the error log to get back in.

• Server commands run in an SSH terminal from the site folder that contains wp-config.php. WP-CLI is wp on most hosts and wp-cli on some.
• File edits happen in File Manager or over SFTP.
• Browser checks use developer tools: F12, or Cmd+Option+I on a Mac.

Step 1: Prove the update caused it

First confirm the version and when it changed:

wp core version --extra
ls -l --time-style=full-iso wp-includes/version.php

These run over SSH with no placeholders. --extra adds the database version and TinyMCE version to the output. The second command shows when version.php was last written, which is normally the moment core updated (the time is in the server’s time zone, which date will show you). On macOS servers, use stat wp-includes/version.php instead. Good evidence: the update time sits just before your first error. If the file is days older than the problem, look elsewhere first.

Next, find the first error after that time in the PHP error log. A line like this is typical:

[DD-Mon-YYYY HH:MM:SS UTC] PHP Fatal error:  Uncaught TypeError: FUNCTION_NAME(): Argument #1 ($string) must be of type string, int given in /PATH/TO/SITE/wp-content/plugins/PLUGIN_SLUG/FILE.php:LINE_NUMBER

This is example log output, not a command. The path tells you who owns the failing code: wp-content/plugins/PLUGIN_SLUG/ is a plugin, wp-content/themes/THEME_SLUG/ a theme, and wp-includes/ or wp-admin/ is core. Even when the fatal error is inside core, the stack trace below it usually names the plugin that called core in an unexpected way. Automatic updates also send an email to the admin address saying the site updated, which gives you another timestamp.

Finally, rule out plugins. On a staging copy, deactivate all plugins and switch to a default theme; if the problem disappears, re-enable them one by one. If it persists with only core running, you may have found a core bug.

Step 2: The 7.1 changes most likely to break things

Integer keys in WP_Hook callbacks

This produced the most visible 7.1 breakage. Since an internal change in 7.1, callbacks that are bare objects (closures or classes with __invoke) could be stored under integer array keys inside WP_Hook::$callbacks instead of the previous string IDs. Plugins that read those keys and pass them to string functions such as substr() hit a fatal “must be of type string, int given” TypeError on PHP 8. The documented case involved WP Rocket together with Elementor Pro, and WP Rocket’s documentation describes a fatal error on WordPress 7.1 fixed in WP Rocket 3.23.2.2. Core tracked it as Trac ticket #65919, “Array keys in WP_Hook::$callbacks may now be integers instead of strings in 7.1 causing fatal errors with string functions”, and the fix shipped in 7.1.1. Update both WordPress and the plugin.

The post editor is now always in an iframe

WordPress has moved its editors into iframes over several releases. In 7.0 the post editor was iframed only when every block in the post used block API version 3. In 7.1 it is always iframed, regardless of theme type, block API versions, or legacy meta boxes. Plugins whose editor scripts reach for the global document or window to touch content now look at the wrong document. Typical symptoms are toolbar buttons that do nothing, missing editor styles, or custom blocks that render unstyled in the editor but fine on the front end. The fix belongs to the plugin or block developer; report it to them with the exact block name.

jQuery UI 1.14.2

7.1 updates jQuery UI from 1.13.3 to 1.14.2. The developer note says jQuery.uiBackCompat is set to true for compatibility, and that $.fn._form, $.ui.ie, $.ui.safeActiveElement and $.ui.safeBlur were removed. Old admin scripts that used those see errors like “$.ui.safeActiveElement is not a function” in the browser console, and the dialog, date picker or sortable list they power stops working.

Client-side media processing

In supported browsers (the full pipeline is Chromium-only), 7.1 resizes images and generates thumbnails in the browser using a WebAssembly build of libvips, then uploads each size. Other browsers fall back to server processing automatically. Points that can surprise you:

• Generated files can differ in size and quality from what GD or Imagick produced before.
• Plugins that hook wp_generate_attachment_metadata (watermarking, CDN sync) receive it twice: once with context create and again with update after a new finalize endpoint runs.
• On editor screens in Chromium 137 and later, WordPress sends a Document-Isolation-Policy header and adds crossorigin="anonymous" to external scripts, which can affect third-party scripts loaded into the editor.

If a media plugin misbehaves, its developer (or you, in a small plugin) can turn the feature off with add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );, which the developer note documents.

Other changes worth knowing

• The admin bar now stays visible inside all editors. Plugins that add toolbar items should be checked there.
• The Media Library grid uses infinite scrolling by default, with a per-user option to return to pagination.
• The notify_post_author filter now has the final say on post author notifications, which can change who receives comment emails if a plugin filters it.
• The Classic block was not hidden in the end; it remains in the inserter in 7.1.

Step 3: Known 7.1 problems fixed in 7.1.1

The 7.1.1 release candidate announcement lists the regressions it addressed. If your symptom matches one of these, the fix is simply to update to the newest 7.1.x, not to roll back:

Symptom	Ticket or pull request
Fatal TypeError from plugins reading hook callback keys	Trac #65919
The native wp-sitemap.xml served with a 404 status on sites with no published posts	Trac #65945
Block style variations losing their gap spacing (spacing.blockGap)	Trac #66044
Layout styles missing for block style variations	Gutenberg #82335
Post editor triggering a 403 on /wp/v2/settings for users without the manage_options capability	Gutenberg #81813
Gallery block “Crop images to fit” broken in the editor	Gutenberg #82318
Client-side processing creating thumbnails larger than the original for indexed PNGs, and claiming “Upload complete” when every upload failed	Trac #65922, Gutenberg #81397
Tooltip bugs, including a misaligned tooltip next to “Remember Me” on the login screen	Trac #65918 and related

Update with:

wp core update
wp core verify-checksums

These run over SSH. wp core update installs the newest release your site is offered. wp core verify-checksums compares every core file against the official checksums for your version. Good output is “Success: WordPress installation verifies against checksums.” Warnings about modified or extra files in wp-admin or wp-includes mean core files are not what they should be, which also deserves attention because it can indicate tampering.

Step 4: Roll back safely, only if you must

Rolling back is a last resort. Every 7.1.x point release after 7.1 contains security fixes, so the correct target is the newest release on the 7.0 branch, which receives those fixes as backports. As of early November 2026 that is 7.0.8 (28 October 2026). Check the WordPress releases archive for anything newer before you run the command.

wp db export before-rollback-YYYY-MM-DD.sql
wp core update --version=7.0.8 --force
wp core verify-checksums

These run over SSH. YYYY-MM-DD is today’s date so you can identify the backup; store the file outside the web root afterward. --version picks the release to install, and --force is required because you are installing a lower version than the current one. Good output ends with “Success: WordPress updated successfully.” followed by a clean checksum check.

Database caveats

• Downgrading replaces files only. Any database upgrade 7.1 ran stays in place, and the older code generally ignores it. To return the database exactly to its pre-update state you need the backup taken just before the update, and restoring it loses every order, comment, form entry and post created since.
• Content made with 7.1 features, such as the new Tabs and Playlist blocks, has no matching block in 7.0. The editor shows those blocks as unsupported, and they may render nothing on the front end.
• Automatic updates will try to move you back to 7.1. Under Dashboard, Updates, switch to automatic updates for maintenance and security releases only, or add define( 'WP_AUTO_UPDATE_CORE', 'minor' ); to wp-config.php. That keeps security backports flowing on the 7.0 branch.

Treat the rollback as temporary. Set a reminder to retest 7.1 once the plugin vendor ships a fix.

Step 5: Report a bug

If you reproduced the problem with all plugins off and a default theme, report it:

• Search first. Search the WordPress.org support forums and core Trac (core.trac.wordpress.org) for your error message. Many 7.1 issues already have tickets, and adding a clear reproduction to an existing ticket is more useful than a duplicate.
• Core Trac takes bugs in PHP, wp-admin screens and core APIs. Log in with your WordPress.org account. Include your exact version, PHP version, steps to reproduce on a clean install, what you expected and what happened, and the error log lines.
• The Gutenberg repository on GitHub takes block editor and Site Editor bugs.
• The “Fixing WordPress” support forum on WordPress.org is the place to ask for help when you are not sure whether it is a bug.
• Security problems must never go in a public ticket or forum post. The WordPress security team takes reports through its HackerOne program.

If the bug is in a plugin, report it in that plugin’s support forum or to its vendor, with the same details.

Advanced: confirm a plugin conflict with a stack trace

A single fatal line names where PHP stopped, not who caused the problem. Turn on full logging temporarily in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

This is a file edit, placed above the “That’s all, stop editing!” line. WP_DEBUG turns on error reporting, WP_DEBUG_LOG writes to wp-content/debug.log, and WP_DEBUG_DISPLAY set to false keeps errors off the page your visitors see. Reproduce the problem once, then read the log:

grep -n -A 12 "PHP Fatal error" wp-content/debug.log | tail -40

This runs over SSH. -A 12 prints the twelve lines after each fatal error, which is where the stack trace lives, and tail -40 keeps only the most recent entries. Read the trace from the top: the numbered lines starting with #0 list each function call that led to the crash. The first line pointing into wp-content/plugins/ or wp-content/themes/ is almost always the code that needs an update. For the WP_Hook issue above, for example, you would see the plugin’s file calling a string function, with core’s hook code higher up the trace. Remove the three lines (or set WP_DEBUG to false) when you are done, and delete debug.log, because it can expose paths and data.

In the browser, the same logic applies to JavaScript. Open the console on the broken screen, expand the red error, and read the stack: the first file under /wp-content/plugins/ is your lead, while files under /wp-includes/js/ are core libraries such as jQuery UI being called the old way.

When to contact your host

Contact your host if the update itself failed partway (for example, the site is stuck in maintenance mode, which our failed updates guide covers), if files cannot be written during the update, or if the error log is not available to you. Send:

• The UTC time of the update and of the first error.
• The output of wp core version --extra and wp core verify-checksums.
• The relevant PHP error log lines, with stack traces.
• Your PHP version and what else changed recently, such as plugin updates or a PHP upgrade.

Use our diagnostic tools to check status codes and headers from outside your network, and if the whole site is down, start at the Emergency Room.