WordPress 7.0 Update Checklist: What Changed and How to Update Safely

WordPress 7.0 "Armstrong" was released on May 20, 2026. It adds an AI client and a Connectors screen to core, a redesigned admin, new blocks and a new minimum PHP version of 7.4. It has since been followed by WordPress 7.1, so a site still on 6.9 that updates today moves straight to the latest 7.1 release, which includes everything in 7.0. Either way, the move to the 7.x branch is safe for a well-maintained site if you update a staging copy first, confirm your PHP version and plugins, take a backup you have tested, and check that WordPress can actually write its own files. That last check is the one most guides skip, and it is the one we tripped over on our own server.

What changed in WordPress 7.0

Everything below is taken from the official WordPress 7.0 release post and the WordPress 7.0 Field Guide for developers. A lot of preview coverage written before release describes features that did not ship, so it is worth sticking to those two sources.

AI building blocks in core

• The WP AI Client, a provider-agnostic interface that lets plugins talk to generative AI models, with WordPress core handling the request routing.
• A Connectors screen under Settings, where AI provider connections are managed in one place. It ships with three presets and accepts others.
• The Abilities API, now integrated with the AI client, plus a new client-side JavaScript counterpart for plugin developers.
• A separate AI plugin, installed on its own, for features such as generating or editing images, writing titles and excerpts, and suggesting alt text.

AI providers have to be connected and authenticated on the Connectors screen before these abilities do anything. For a business site, the practical point is to decide who is allowed to connect an AI provider, and with whose account, before a plugin asks.

A modernized dashboard

• A new default admin color scheme called "Modern" and smooth transitions between admin screens.
• A Command Palette shortcut in the admin bar, so the palette is one click away from any admin screen.
• A dedicated font management page, so fonts can be uploaded and managed in one place.
• Visual Revisions, which let editors compare two versions of a post in the editor, moving between them with a slider.

Blocks and design

• New Heading, Breadcrumbs and Icons blocks, and a lightbox slideshow for the Gallery block.
• Show or hide individual blocks by device, without affecting other screen sizes.
• Mobile navigation overlays that can be designed with blocks and patterns.
• Custom CSS on an individual block, set from the editor.
• Patterns that behave as a single unit, with content-only editing applied more broadly.

Under the hood

• PHP 7.4 is the new minimum. Support for PHP 7.2 and 7.3 was dropped.
• Blocks and patterns can be registered with PHP alone.
• The Site Editor gained routing and a package that lets plugins add their own Site Editor pages.
• Administrator and Editor were removed from the "New User Default Role" setting, and Site Health warns if one of them had been selected.

What did not ship

Real-time collaboration, several people editing the same post at once, was the headline feature for most of the development cycle. On May 8, 2026, it was removed from WordPress 7.0, with stability and server load given among the reasons. If an article tells you 7.0 has live co-editing, it was written before that decision.

And then WordPress 7.1

WordPress 7.1 followed on August 19, 2026. For an update plan, the change that matters most is that the post editor now runs inside an iframe for all themes, which can affect older custom blocks and editor styling. It also added responsive style controls, Tabs and Playlist blocks, and image processing in the browser. At the time of writing, the current release is 7.1.3, a security release from October 6, 2026.

Before you update to WordPress 7.0: the checklist

1. Confirm your real PHP version

WordPress 7.0 needs PHP 7.4 or newer. A site on PHP 7.2 or 7.3 is not offered 7.0 at all and stays on the 6.9 branch. That sounds safe, but it means the site has quietly stopped receiving new WordPress releases.

WordPress recommends PHP 8.3 or newer, and its compatibility table lists PHP 7.4 through 8.5 as supported for both 7.0 and 7.1. Check the version under Tools, then Site Health, then Info, then Server. Do not rely on php -v or wp --info in a terminal: the command-line PHP is often a different version from the one serving your website.

Also check where your PHP version stands on PHP's own support schedule on php.net. PHP 8.2 receives security fixes only until December 31, 2026. If you are moving PHP and WordPress in the same season, do them as two separate steps, each tested on staging, so that if something breaks you know which change caused it.

2. Check plugins and the theme against the new version

Most breakage after a major update comes from plugins and themes, not core. List what you have, what is out of date, and what each plugin declares about compatibility:

# Installed plugins with available updates and declared compatibility
wp plugin list --fields=name,status,version,update_version,tested_up_to,requires_php

# Same for themes
wp theme list

Update plugins and the theme on staging first, then core. Pay particular attention to:

• Custom blocks and older block plugins. In 7.0 the post editor only uses the iframe when every block in the post uses version 3 of the block API. In 7.1 it uses the iframe for all themes. Blocks or editor styles that assume they are in the main admin page can look wrong or stop working.
• Pattern-heavy sites. Content-only editing now applies to more patterns. Check that editors can still change what they need to.
• Premium plugins with lapsed licences. They do not show updates in the dashboard, so they look up to date when they are not. Check the vendor's changelog directly.
• Abandoned plugins. If a plugin has had no update in a long time, plan its replacement rather than hoping it survives.

3. Take a backup you have actually restored

The official upgrade guide says to back up the database and all files, including .htaccess, and then verify that the backups are usable. The verification is the part that gets skipped. A database export takes seconds:

# Database export with today's date in the filename (store it off the server)
wp db export ~/backups/before-7x-$(date +%F).sql

Keep a file backup of the whole WordPress directory too, and keep both somewhere other than the server itself. Then restore them onto staging at least once. A backup that has never been restored is a hope, not a plan.

4. Update a staging copy first

Clone the live site to staging, update everything there, and test the things that make you money: forms, logins, checkout and account pages for a store, and the editor for whoever writes your content. Compare the important pages before and after. When we moved a client off PHP 7.4 in our PHP upgrade case study, we recorded a baseline of every page type on staging first, then compared the rendered output across nine page types afterwards. It came out identical on all nine. That is the standard to aim for: showing nothing changed, not assuming it.

5. Make sure WordPress can update its own files

This one deserves its own section, because it fails silently.

File ownership: why WordPress 7.0 updates can fail without telling you

On our own server we keep about 28 WordPress sites. When they moved to the 7.0 branch, we found files owned by the wrong system user, and that had silently stopped core updates from applying. Nothing on the sites looked broken. They simply did not update.

The reason is in how WordPress decides whether it can write files. Before an update, it creates a temporary test file and compares that file's owner with the owner of its own files. Only if they match does it write directly. If they do not, WordPress falls back to asking for FTP or SSH credentials. In the dashboard you see a credentials form. Automatic background updates, including the urgent security releases, have nobody to fill that form in, so they do not happen.

That matters more than it used to. When WordPress 7.0.2 fixed a critical and a high-severity vulnerability in July 2026, the WordPress.org team enabled forced updates through the automatic update system because of the severity. A forced update still needs WordPress to be able to write its files. A site with the wrong ownership misses exactly the update it most needs.

How files end up with the wrong owner

• Restoring a backup, unzipping files or running a migration as root.
• Running WP-CLI or a deployment script as root or as a different user from the one PHP runs as.
• Copying a site between accounts without resetting ownership.

How to check

Start in the dashboard. Under Tools, then Site Health, look for "Background updates are working". If it says background updates may not be working properly, expand it. WordPress checks whether it can write to its files directly, whether every core file is writable, and whether a previous automatic update failed. The tell-tale message is "Your installation of WordPress prompts for FTP credentials to perform updates", which WordPress follows with a note that this is due to file ownership. Then confirm on the server:

# Who owns the core files? (run in the WordPress directory)
stat -c '%U:%G %n' wp-load.php wp-includes/version.php wp-admin/index.php

# List anything in the site that is NOT owned by the site's user
# (replace siteuser and the path with yours; -print | head keeps the output short)
find /var/www/example.com/public ! -user siteuser -print | head -50

How to fix it

WordPress's own file permissions guidance is that files should be owned by your user account and writable by it, and that on shared hosting they should never be owned by the web server's own user. On setups where PHP runs as your account user, which WordPress recommends, the fix is to give everything back to that user:

# Back up first. Run as root or with sudo, and check the path twice.
chown -R siteuser:siteuser /var/www/example.com/public

# Typical modes: directories 755, files 644
find /var/www/example.com/public -type d -exec chmod 755 {} ;
find /var/www/example.com/public -type f -exec chmod 644 {} ;

# wp-config.php is the exception: 440 or 400, so other users cannot read it
chmod 440 /var/www/example.com/public/wp-config.php

Some servers deliberately run PHP as a different user and rely on group permissions. Changing ownership on those can break uploads. If you are not sure how your server runs PHP, ask your host before running chown.

Resist the shortcut of forcing FS_METHOD to direct in wp-config.php. The WordPress documentation warns that direct file access can open security issues on poorly configured hosts and that the constant should only be changed for genuine update problems. Fixing ownership fixes the cause.

How to update to WordPress 7.0 or 7.1 safely

With staging tested and backups in hand, the live update itself is short. From the dashboard, go to Dashboard, then Updates, and update plugins and themes before WordPress itself. From the command line:

# What is available?
wp core check-update

# Back up, then update core to the latest release
wp db export ~/backups/pre-update-$(date +%F-%H%M).sql
wp core update

# Run any database changes the new version needs
wp core update-db

# Confirm every core file matches the official copy
wp core verify-checksums

If WP-CLI reports "Another update is currently in progress", the WP-CLI documentation's advice is to confirm no update is actually running before deleting the lock with wp option delete core_updater.lock.

Update at a quiet time, with someone available to check the site for the next hour.

After the WordPress 7.0 update: what to check

• Load the key pages logged out, then clear every cache layer: plugin, server and CDN.
• Test forms, logins and payments. For WooCommerce, place a test order end to end.
• Open the editor on a few real posts, especially ones that use custom blocks or patterns.
• Check Settings, then General, then New User Default Role. If Site Health warns about it, set it to Subscriber or another low-privilege role unless you have a specific reason not to.
• Run Site Health again and confirm background updates are working.
• Watch the error log for new PHP warnings over the next few days.
• Keep the pre-update backup until you are confident the site is stable.

Keeping the 7.x branch updated

The update is not a one-off. Between 7.0 in May and early October 2026 there were seven point releases on top of 7.1, and six of the seven were security releases. Only the most recent version of WordPress is actively supported; security fixes are backported to older branches as a courtesy where possible. The next major version, 7.2, is currently planned for December 2026.

If you want security releases to apply automatically while you still test major versions on staging, WordPress supports exactly that in wp-config.php:

// Apply minor (maintenance and security) core updates automatically.
// Major versions are tested on staging first and applied by hand.
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

That only works if background updates can write the files, which brings you back to ownership. Our maintenance plans include tested updates, daily off-site backups and uptime, SSL and security monitoring, which is the routine that catches a site that has quietly stopped updating.

Common questions

When was WordPress 7.0 released?

WordPress 7.0 "Armstrong" was released on May 20, 2026, after the release cycle was extended from an original April target. WordPress 7.1 "Mary Lou" followed on August 19, 2026.

Should I update to WordPress 7.0 or 7.1?

Update to the latest release, which is 7.1.x at the time of writing. It contains everything in 7.0 plus later fixes, including security fixes. Only the most recent branch is actively supported. Test on staging first either way.

What PHP version does WordPress 7.0 need?

The minimum is PHP 7.4. WordPress recommends PHP 8.3 or newer, and lists PHP 7.4 to 8.5 as supported for 7.0 and 7.1. Sites on PHP 7.2 or 7.3 stay on WordPress 6.9 until PHP is upgraded.

Does WordPress 7.0 include real-time collaboration?

No. Real-time collaboration was removed from 7.0 shortly before release, and the core team said a plan for further testing would follow. Editors can still use Visual Revisions to compare versions.

Will my plugins break when I update to WordPress 7.0?

Well-maintained plugins generally will not. The risk sits with abandoned plugins, premium plugins whose licences have lapsed so they have not been updated, and custom blocks or editor styles that are not ready for the iframed editor. Update and test everything on staging first, and check each plugin's changelog for 7.x compatibility.

Why is WordPress not updating automatically?

The most common causes are a constant in wp-config.php that disables updates, a broken scheduled task system, and files owned by a different user from the one PHP runs as. Site Health's "Background updates" check tells you which, and fixing file ownership is often the answer.

Next step

If you would rather have updates tested on staging, backups verified and file ownership checked for you, our WordPress maintenance plans start at $59 a month, and WooCommerce store maintenance is $299 a month. For a site that is stuck on old PHP or an old WordPress branch, start a project and we will send a written scope and a fixed price.