WordPress 7.0 Broke My Site: Known Issues and Fixes

WordPress 7.0 “Armstrong” arrived on 20 May 2026, later than its original April date, and it was a big one: a redesigned admin with a new “Modern” color scheme, AI building blocks, a new Font Library page, visual revisions, block-level custom CSS, new blocks, and a higher minimum PHP version. If your site started misbehaving around then, with a critical error, an editor that behaves differently, patterns you can no longer edit freely, or an update that never appears, this guide helps you work out whether 7.0 is responsible and what to do about it.

Most problems after 7.0 trace back to a handful of deliberate changes documented in the official WordPress 7.0 Field Guide, plus a set of regressions fixed in 7.0.1. Below you will find each change explained in plain terms, the symptoms it produces, how to confirm the cause from your logs and browser, how to roll back if you truly must, and how to report a genuine bug.

What is happening

A major release changes core behavior that themes and plugins depend on. When a plugin relied on something that changed, the plugin breaks, even though core is working as designed. When core itself has a mistake, a point release on the same branch fixes it. The 7.0 branch has had eight point releases so far:

Release	Date	Contents
7.0	20 May 2026	Feature release
7.0.1	9 July 2026	Fixes for 31 bugs in core and the block editor
7.0.2	17 July 2026	One critical and one high severity security fix; WordPress.org enabled forced automatic updates for affected sites
7.0.3	6 August 2026	Twelve security fixes
7.0.4	12 August 2026	One security fix for sites using Imagick and Ghostscript
7.0.5 to 7.0.8	17 September to 28 October 2026	Security fixes backported from the 7.1 branch

Because of 7.0.2’s forced updates, many sites changed version without anyone clicking a button. That matters when you are matching error times to update times.

Before you start

You need an administrator login and either SSH or your hosting control panel. Back up files and database first. If you cannot reach the dashboard at all, our critical error guide covers recovery mode.

• Server commands run in an SSH terminal from the site folder containing wp-config.php, using wp or wp-cli depending on your host.
• Browser console commands run in developer tools (F12, or Cmd+Option+I on a Mac), on the screen named in the step.
• File edits happen in File Manager or over SFTP.

Step 1: Check PHP first, because 7.0 raised the minimum

WordPress 7.0 dropped support for PHP 7.2 and 7.3. The new minimum is PHP 7.4, while the recommended version stays at PHP 8.3. The core team’s announcement said sites on PHP 7.2 or 7.3 stay on the 6.9 branch, which continues to get security fixes as backports.

wp eval 'echo PHP_VERSION, PHP_EOL;'
wp core check-update

These run over SSH with no placeholders. The first prints the PHP version WP-CLI uses, which can differ from the web server’s; confirm it under Tools, Site Health, Info, Server. The second lists the core updates available to this site. If PHP is below 7.4, WordPress will not offer 7.0 or later at all. Forcing it fails with “The update cannot be installed because WordPress 7.0 requires PHP version 7.4 or higher. You are running version PHP_VERSION.” The fix is to upgrade PHP, which our PHP upgrade guide walks through safely, then update WordPress.

If you are on PHP 7.4 or newer and the site broke after 7.0, continue.

Step 2: Prove the update caused it

Compare the update time with the first error:

wp core version --extra
stat -c '%y' wp-includes/version.php

These run over SSH. The first shows the WordPress version and database revision. The second prints when version.php was last modified, normally the moment of the update (on BSD or macOS systems use stat wp-includes/version.php without -c). Now open the PHP error log and find the first entry after that time. A fatal error naming wp-content/plugins/PLUGIN_SLUG/ or wp-content/themes/THEME_SLUG/ points at that plugin or theme, even if core changed underneath it.

To confirm, reproduce on a staging copy with every plugin deactivated and a default theme active. If the problem disappears, re-enable plugins one at a time. If it survives with nothing but core, it may be a core bug: see Step 6.

Step 3: The 7.0 changes most likely to break things

Patterns are locked to content-only editing more often

7.0 applies contentOnly mode more broadly: patterns that previously allowed free editing of their inner blocks now default to content-only, so editors can change text and images but not the layout. Clients often report this as “I can’t move or delete blocks inside the pattern anymore.” The Field Guide documents an opt-out for unsynced patterns: the disableContentOnlyForUnsyncedPatterns editor setting, set through the block_editor_settings_all PHP filter. Developers of custom blocks used inside patterns should mark content attributes with "role": "content" in block.json, or those attributes cannot be edited and the blocks may be hidden in List View.

The editor iframe depends on block API versions

In 7.0 the post editor runs inside an iframe when every block inserted in the post uses block API version 3 or higher; if any older block is present, the iframe is dropped for compatibility. That means the same site can show two different editor behaviors depending on which blocks a post contains. A plugin block that styles correctly on one post and not another is a classic sign. The Advanced section shows how to list the older blocks.

The admin redesign

The new admin color scheme, typography and screen transitions restyle core screens. Plugin settings pages that hard-coded colors or relied on old admin markup can look broken or low-contrast. Editor component bottom margins were removed and margin-free styles became the default, which can make plugin panels in the editor look cramped. These are cosmetic; report them to the plugin vendor.

Library and API updates

• PHPMailer 7.0.2, including a Sender address fix. Custom mail code that sets the sender by hand should be retested; our WordPress email guide covers diagnosis.
• Requests 2.0.17, Backbone 1.6.1, and the latest CodeMirror 5, with Esprima replaced by Espree for JavaScript linting in the code editors.
• HTML5 script theme support was deprecated and removed (Trac #64442). Themes declaring it no longer need to.
• New user default role: Administrator and Editor are no longer offered as the default role for new users under Settings, General. Site Health warns if one of them was selected before the update, and the default_role_dropdown_excluded_roles filter changes the excluded list. If registrations suddenly get a different role, check this setting.
• Title attributes were removed by default from three author link functions, which can change markup that CSS or tests target.

Step 4: Known 7.0 problems fixed in 7.0.1

The 7.0.1 release candidate announcement lists the regressions it addressed. If your symptom matches one of these, update to the newest 7.0.x or later instead of rolling back:

Symptom	Ticket
wp_kses() corrupting valid inline CSS background-image: url(...) declarations into a broken style attribute, so background images in content disappeared	Trac #65270
The global-styles-inline-css stylesheet could not be removed by themes and plugins that dequeue it	Trac #65336
Code calling block_core_navigation_submenu_render_submenu_icon() after it was removed; 7.0.1 restored it as a deprecated shim	Gutenberg #78484
Emoji detection script not printed in the admin	Trac #65310
Incorrect array access in wp_get_attachment_image_src on PHP 8.5	Trac #64742
A black flash on wp-admin pages before they finish loading	Gutenberg #78493
Admin reskin problems: unstandardized form elements on mobile, crowded publish buttons, misaligned media screens	Trac #64999, #65286 and related

wp core update
wp core verify-checksums

These run over SSH. The first installs the newest release offered to your site; the second checks every core file against official checksums. Good output from the second is “Success: WordPress installation verifies against checksums.” Any reported mismatch in wp-admin or wp-includes means a core file was changed or left behind and should be investigated.

Step 5: Roll back to 6.9 safely, only if you must

Roll back only when a critical plugin cannot work on 7.0 and no fix exists yet. The safe target is the newest 6.9.x release, because the security fixes from every 7.0.x release were backported there. As of early November 2026 that is 6.9.11, released on 28 October 2026; check the WordPress releases archive for anything newer first.

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

These run over SSH. YYYY-MM-DD is today’s date for the backup file name; move the file out of the web root afterward. --version chooses the release, and --force allows installing a lower version than the current one. Good output ends with “Success: WordPress updated successfully.” and a clean checksum result.

• The database is not rolled back. Whatever upgrade routine 7.0 ran stays. Only the backup taken right before the update restores the old state, at the cost of everything written since.
• New blocks break. Breadcrumbs, Icons and other blocks introduced in 7.0 do not exist in 6.9, so posts using them show unsupported blocks in the editor and may lose that output on the front end. Block-level custom CSS added in 7.0 will not apply.
• Automatic updates will undo it. Under Dashboard, Updates, switch to maintenance and security releases only, or set define( 'WP_AUTO_UPDATE_CORE', 'minor' ); in wp-config.php. Security releases may still be pushed when the issue is severe, as happened with 7.0.2.

Step 6: Report a bug

Before reporting, search the WordPress.org support forums and core Trac (core.trac.wordpress.org) for your exact error text. If you find a matching ticket, add your reproduction steps there.

• File core PHP, admin and API bugs on Trac, logged in with a WordPress.org account. Include WordPress and PHP versions, numbered steps that reproduce the issue on a clean install with a default theme, expected and actual results, and log lines.
• File block editor, pattern and Site Editor bugs in the Gutenberg repository on GitHub.
• Ask in the “Fixing WordPress” forum on WordPress.org when you are not yet sure it is a bug.
• Report security issues privately through the WordPress security team’s HackerOne program, never in public.

Advanced: find blocks that keep the editor out of the iframe

If a block looks or behaves differently from post to post in 7.0, check which registered blocks still use an older block API version. Open the post editor, open the browser console, and run:

wp.blocks.getBlockTypes().filter( ( b ) => ( b.apiVersion || 1 ) < 3 ).map( ( b ) => b.name + ' (v' + ( b.apiVersion || 1 ) + ')' );

This runs in the browser console on the post editor screen, and it changes nothing. It lists every registered block whose API version is below 3, treating a missing value as version 1, in the form PLUGIN_NAMESPACE/BLOCK_NAME (v2). An empty list is good: your posts get the iframed editor consistently. Names with a namespace such as PLUGIN_NAMESPACE/ belong to plugins; insert any one of them into a post and that post’s editor drops the iframe. Send the list to the plugin vendors and ask for API version 3 updates, because 7.1 makes the iframe permanent for every post.

To see which mode you are in right now, run document.querySelector( 'iframe[name="editor-canvas"]' ) !== null in the same console. true means the editor canvas is in an iframe; false means it is not.

For PHP problems, the same principle applies with a stack trace. Temporarily set WP_DEBUG and WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false in wp-config.php, reproduce the error once, and read wp-content/debug.log. The first frame in the trace that points into wp-content/ is the code that needs updating. Turn debugging off and delete the log afterward.

When to contact your host

Contact your host if PHP cannot be upgraded to 7.4 or newer from your control panel, if the update failed and left the site in maintenance mode (see our failed updates guide), or if you cannot see the error log. Send:

• The UTC times of the update and of the first error.
• The output of wp core version --extra, wp core verify-checksums and your PHP version.
• The error log lines with stack traces.
• What else changed around the same time, such as plugin updates.

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