WordPress 7.0 ships May 20. What actually changes and what it'll break on your site

TL;DR

WordPress 7.0 ships on May 20, 2026. Three things you have to care about as an admin. First, the minimum PHP version is 8.3, so if your hosting is still on 8.1 or 8.2 the core update will refuse to run. Second, the new Web Client AI API gives plugins a single native interface to OpenAI, Anthropic and Gemini, so plugin authors will stop bundling their own SDKs and shoving API keys into options fields. Third, you can now register a block entirely on the PHP side, no block.json, no JS. Real-Time Collaboration, the one people expected in 7.0, was dropped from the roadmap and is now scheduled for 7.1. The rest of this article is the actual upgrade procedure, the plugin list you need to test on staging and the rollback plan for when something goes sideways.

PHP 8.3 is required. How to check and bump

The fastest check is one SSH command.

ssh user@yourdomain.com 'php -v'

If you see PHP 8.3.x, you are home. If you see PHP 8.2.x or older, WP-CLI will refuse to update core to 7.0 with the message Your server is running PHP version 8.2.x but WordPress 7.0 requires at least 8.3. A plain wp core update in this situation does nothing but print the error.

On mDiv hosting you switch the PHP version in the panel under Sites -> [domain] -> PHP, dropdown with the available versions. After the switch wait 30 seconds, re-run php -v, confirm 8.3 actually loaded. If it did not, php-fpm restarts automatically after a panel change, so the worst case is one minute.

Before you bump PHP on production, build a list of plugins emitting deprecation warnings on the current 8.2.

wp plugin list --status=active --format=csv > active-plugins.csv
wp plugin deactivate --all
wp plugin activate --all 2>&1 | tee deprecation.log
grep -i "deprecated\|warning" deprecation.log

If you see plugins with Deprecated: Creation of dynamic property or Deprecated: Return type of, those are your candidates for breakage on 8.3. Usual suspects are stale cargo-cult plugins copied from forums five years ago, whose authors stopped patching long since. Before going further, check if they have an update. If they do not, and the last commit is three years old, you have a call to make, is the plugin important enough to patch yourself, or is it time to find a replacement.

Web Client AI API. What it is and when it's useful

In 7.0 core gains WP_AI_Client. This is not an AI model inside WordPress. It is a thin abstraction layer over OpenAI, Anthropic and Gemini that unifies the call, the auth and the response format. API keys live in Settings -> AI providers once, at the site level. Every plugin that wants to use this goes through the shared endpoint, no own SDK, no key embedded in an options field.

Why this matters. Until now, if you ran three AI plugins (SEO, product description generator, in-editor assistant), each one had its own form for the OpenAI key, each one potentially a different model version, each one configured separately. After 7.0 all of those plugins, if the author does the right thing, read the key from one place.

Plugin-level call example, literally 15 lines.

<?php
add_action('wp_insert_post', function ($post_id, $post) {
    if ($post->post_status !== 'publish' || $post->post_type !== 'post') {
        return;
    }
    if (get_post_meta($post_id, '_meta_description', true)) {
        return;
    }
    $client = WP_AI_Client::get('openai');
    $response = $client->chat([
        'model'    => 'gpt-4.1-mini',
        'messages' => [
            ['role' => 'system', 'content' => 'Generate a meta description in English, up to 155 chars, no quotes.'],
            ['role' => 'user',   'content' => wp_strip_all_tags($post->post_content)],
        ],
    ]);
    update_post_meta($post_id, '_meta_description', $response->text());
}, 10, 2);

This is a real use case, automatic meta description on publish. In 6.x the same code would have required pulling a library via Composer, your own HTTP error handling and your own cache. In 7.0 WP_AI_Client ships with a built-in rate limiter, retry with backoff and optional response caching in wp_options.

Where it pays off. Generating alt text for images, suggesting categories for a post, drafting a newsletter summary. Anywhere you used to pay for a premium plugin that was a thin wrapper around the OpenAI API.

PHP-only block registration. Less JS, more PHP

In 6.x registering a custom Gutenberg block always required JS. A block.json file, an index.js file, a webpack build via @wordpress/scripts, an entry in enqueue_block_editor_assets. For a block that shows a quote with an author this meant five files and a webpack config.

In 7.0 you can do this.

<?php
// PHP-only version, works after 7.0
register_block_type('mdiv/quote-author', [
    'title'           => 'Quote with author',
    'category'        => 'text',
    'icon'            => 'format-quote',
    'attributes'      => [
        'quote'  => ['type' => 'string', 'default' => ''],
        'author' => ['type' => 'string', 'default' => ''],
    ],
    'render_callback' => function ($attrs) {
        return sprintf(
            '<blockquote class="mdiv-quote"><p>%s</p><cite>%s</cite></blockquote>',
            esc_html($attrs['quote']),
            esc_html($attrs['author'])
        );
    },
    'editor_fields'   => [
        'quote'  => ['type' => 'textarea', 'label' => 'Quote text'],
        'author' => ['type' => 'text', 'label' => 'Author'],
    ],
]);

Diff against 6.x. Previously you also had to write JS edit and save functions and register them through wp.blocks.registerBlockType. Now editor_fields tells Gutenberg what to render in the right-hand sidebar in the editor, and render_callback paints the frontend. For form, FAQ, pull-quote and link-list blocks this saves hours. When it makes sense. Anywhere a block does not need its own UI in the editor, just a handful of fields and server-side render. When it does NOT make sense. If you are building something interactive, drag-and-drop, with a live preview of a complex structure, you still need JS. This API does not replace the full SDK, it is a shortcut for 80% of cases.

What did NOT make it into 7.0. Real-Time Collaboration dropped

At State of the Word in January 2026, Matt Mullenweg called Real-Time Collaboration the flagship feature of 7.0. In April, after RC2, the feature was punted to 7.1. The reasons you can read in the issue tracker boil down to two problems.

First, race conditions on concurrent block editing by two users, one starts typing in a paragraph, the other deletes it, the frontend ends up three lines out of sync. The CRDT Gutenberg used (Yjs) is great for linear text but Gutenberg holds a tree of blocks with attributes, and conflicts there are harder to resolve automatically.

Second, memory consumption. Four people editing the same post at the same time could blow up a site with the default 256MB PHP limit. In Automattic's staging they ended up needing 512MB on a production-class box. For sites on shared hosting that is a non-starter.

ETA for 7.1 is November 2026. If your client bought into WordPress on the promise of real-time editing, you need to tell them it is not landing on May 20. Half-year workaround, plugins like Multicollab or Frontkom Yoast Collab, which solve it in their own way and already work today.

Upgrade procedure for a production site

Order. PHP first, plugins next, core last. Never the other way around.

Step 1. Staging. Clone production to a subdomain like staging.yourdomain.com. On mDiv this is a one-click operation in the panel, on other hosts wp-cli + wp db export + rsync. Confirm staging boots, login works, pages render.

Step 2. Database snapshot.

wp db export backup-before-7.0-$(date +%F).sql

Keep it outside public_html. If anything goes wrong, this file saves you.

Step 3. File snapshot.

tar czf wp-content-before-7.0-$(date +%F).tar.gz wp-content/

Step 4. Bump PHP to 8.3 (staging first). Confirm the site still works, no new fatals in error_log. Give it 24h of observation.

Step 5. Plugins. Update all of them to the latest versions before you touch core.

wp plugin update --all

After each update glance at the frontend and error_log.

Step 6. Core.

wp core check-update --version=7.0
wp core update --version=7.0
wp core update-db

update-db matters. After a major update WordPress migrates the schema and until you run it, some plugins may emit SQL errors.

Step 7. Validation. Check:

• frontend home page and three subpages,
• login to wp-admin,
• contact forms (most common upgrade casualty),
• WooCommerce checkout, if you run a shop,
• crons (wp cron event list).

Rollback plan if after an hour you see something is wrong.

# Roll core back
wp core update --version=6.8.2 --force

# Restore the database
wp db import backup-before-7.0-2026-05-19.sql

# Restore wp-content
tar xzf wp-content-before-7.0-2026-05-19.tar.gz

# Roll PHP back from 8.3 to 8.2 in the panel

The whole rollback takes five minutes, if you have the files on hand. That is why a pre-upgrade snapshot is not optional, it is a precondition.

To stop future versions from auto-installing themselves at the wrong moment, in wp-config.php add.

define('WP_AUTO_UPDATE_CORE', 'minor');

This lets WordPress self-patch 7.0.1, 7.0.2, but 7.1 will wait for your decision.

What the upgrade will break

Five plugin categories that most often fall over at major updates. Test each on staging before you touch production.

Page builders, that is Elementor, Beaver Builder, Bricks. Page builders hook deep into content rendering. If WordPress changes the the_content filter chain (and 7.0 does, via the new block content renderer), builders can show an empty editor or duplicate content. Test, open any page built in the builder, confirm all sections show. Open the same page in the editor, confirm all widgets show.

Cache plugins, WP Rocket, W3 Total Cache, LiteSpeed Cache. After every major update clear cache at both layers, the plugin and the hosting (OPcache, object cache). Most common symptom of skipping this, the frontend serves old HTML with deprecated functions even though core is already on 7.0. WP Rocket has a known issue with minification after major updates, if you see your CSS go sideways, turn minification off and turn it back on after an hour.

Security plugins, Wordfence, Sucuri, iThemes Security. Wordfence ships its own WAF ruleset tied to a specific core version. After an upgrade the vendor has to push a rules update, usually within 24h. In that window you may see false positives, e.g. legitimate admin traffic blocked. Whitelist your admin IP in Wordfence before the upgrade.

Form plugins, Contact Form 7, WPForms, Gravity Forms. Least obvious category, most often broken. The reason, forms often use wp_mail() with very specific workflows, and 7.0 changes how core handles wp_mail with an HTML body. Test, send a test mail from every form and verify it arrived.

Translation plugins, WPML, Polylang. These plugins reach deep into WP_Query, into URL routing, into the_post. WPML in versions before 4.7 has a known incompatible patch with 7.0, if you are on an older version, update WPML BEFORE core. Polylang has had this sorted since March, but still, test switching between languages.

How to read error_log

After the upgrade, first place you look is wp-content/debug.log (if you have WP_DEBUG_LOG enabled) or the host's PHP log, usually ~/logs/error.log. Turn debugging on temporarily on staging.

// wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

What to look for.

• Fatal error is an instant stop, site is down, react now.
• Uncaught Error is the white screen of death, usually with a specific file and line that points you at the offending plugin.
• Deprecated on PHP 8.3 does not stop the site, but if you see hundreds per minute, that plugin is on borrowed time.

How to identify the plugin causing a fatal when the site is already down and wp-admin will not load.

# Rename the plugins directory, WordPress disables all of them
mv wp-content/plugins wp-content/plugins.off
# Check wp-admin loads
mv wp-content/plugins.off wp-content/plugins
# Re-enable one by one
wp plugin activate {name}

Classic binary search, in 5-7 steps you have the culprit.

Official sources

• WordPress 7.0 Field Guide, full list of breaking changes, deprecations and new APIs.
• Release Candidate 4 announcement, official RC with changes vs RC3.
• PHP 8.3 release notes, so you know what WordPress is actually enforcing.

What we do under the mDiv maintenance plan

A major core update is not a click of "update now" in the panel. It is staging, snapshot, order of operations, rollback plan, frontend and checkout testing. If you run a site where an hour of downtime is a real cost, this is not Sunday afternoon work.

In our Pro and Premium maintenance packages we perform major updates (like the upcoming 7.0) following the procedure above, in a night window, with a full rollback plan. The client gets a report on what was updated, what was tested and what still needs attention.

If your site is sitting on PHP 8.1 or 8.2 and you are not sure it will survive May 20, reach out or get a quote for a move to hosting with PHP 8.3 and automated updates.