Table of Contents
TL;DR
- WordPress 7.0 "Armstrong" raises the minimum PHP version to 7.4. RC4 landed on May 14 2026 before the May 20 final release.
- The safe upgrade follows the same shape as any major WordPress release. Backup first. Core first. Themes second. Plugins third. One at a time.
- Check your PHP version before you click Update. The host control panel shows it. Most managed hosts already run PHP 8 and the upgrade is fine.
- Use a staging copy if your host offers one. If not, the free WP Staging plugin gives you a private copy for fifteen minutes of testing.
- Hold off on plugins that touch payment, membership, or e-commerce until you have tested them on staging. The rest can wait a quiet evening.
You open the dashboard on a Tuesday morning and see a banner. WordPress 7.0 is available. There is a blue Update Now button.
The instinct is to click. The instinct is wrong.
A major WordPress release is not a Tuesday-morning task. It is a Saturday-afternoon task, with a backup, a staging copy, and twenty minutes of patient clicking.
This article walks the safe shape of that Saturday afternoon. It is meant for the small business owner who runs her own site and would like to upgrade to WordPress 7.0 without losing the contact form, the checkout flow, or a night of sleep.
What does WordPress 7.0 actually require of your site?
WordPress 7.0 raises the minimum PHP version to 7.4. RC4 landed on May 14 2026 before the May 20 final release. The release notes for the upgrade live on the official WordPress release page.
PHP is the programming language WordPress runs on. Your hosting account picks the PHP version. If your host runs PHP 7.3 or older, the upgrade will refuse to start until PHP is updated.
Most managed WordPress hosts already run PHP 8.x. Most basic shared hosts moved to PHP 8 in 2025. A small number of older shared accounts still run PHP 7.2 or PHP 7.3. Those accounts need a PHP update before WordPress 7.0 will install.
The other requirements are familiar. MySQL 5.7 or higher (or MariaDB 10.4 or higher). HTTPS on the site. Disk space, which is always plenty for a small site.
The Updates screen in wp-admin will tell you in plain English if your host does not meet the requirements. If it does not say anything, your host is ready.
How do you check your PHP version in five minutes?
Two clicks in wp-admin. Open Tools, then Site Health. Click the Info tab at the top. Scroll to the Server section.
The PHP version sits on the first line. If it reads 7.4 or higher, you are clear for the WordPress 7.0 upgrade. If it reads anything older, you need a PHP update first.
The PHP update happens in the hosting control panel, not in wp-admin. Most cPanel-style hosts call it "Select PHP Version" or "MultiPHP Manager". Most managed hosts (Kinsta, WP Engine, Pressable, Flywheel) let you switch PHP from the site dashboard.
The safe shape of a PHP update is the same shape as a WordPress upgrade. Take a backup. Switch the PHP version.
Reload three or four pages. If the site holds, you are done. If something breaks, switch the PHP version back.
A reader who runs a small site on a low-cost shared host should ask the host’s support channel before changing PHP. Some shared hosts move PHP for you on request, and that is safer than guessing.
What is the safe upgrade workflow for WordPress 7.0?
Five steps. The whole workflow takes twenty minutes for a small site that has been kept up to date.
Step 1. Take an off-site backup. The free UpdraftPlus plugin sends a fresh backup to a free Google Drive folder, a free Dropbox folder, or a free Backblaze account.
The destination matters more than the cadence. A backup on the same server is not a backup against an upgrade gone wrong.
Step 2. Update WordPress core first. The Updates screen shows the core upgrade above the plugin and theme lists. Apply it.
Reload the homepage. Click through three or four pages.
Open one post. Open the Plugins screen. If the site survives, move on.
Step 3. Update themes second. Theme updates rarely break catastrophically. Apply one at a time and reload the site between each.
Step 4. Update plugins third, one at a time. The dashboard offers a Select All checkbox above the plugin list. Avoid it.
Update one plugin, reload the site, click through three or four pages, and only then move to the next.
Step 5. If anything breaks at any step, roll back from the off-site backup before moving on. The cost of rolling back is small. The cost of stacking another upgrade on top of a broken state is large.
The full version of this workflow lives in the safe-update guide. The 7.0 upgrade follows the same shape as every other safe update on the site.
When should you upgrade on staging first, and when can you upgrade live?
Use staging when the site does anything where a silent break would cost money or a customer. The shortlist is short:
- A WooCommerce checkout.
- A membership plugin.
- A booking flow.
- An LMS that takes a payment.
Staging is a private copy of the site at a hidden URL. The well-maintained managed hosts ship a one-click staging feature. The basic shared hosts do not, and the free WP Staging plugin fills the gap for them.
The staging workflow for a 7.0 upgrade is the same as for any major release. Push the live site to staging. Run the full upgrade workflow on staging.
Click through every important page on the staging copy. Confirm the contact form sends, the checkout completes, and the login screen works.
If staging survives, the live upgrade is safe. If staging breaks, you fix on the copy and never touch the live site.
A static brochure site without forms or checkout can usually skip staging, run the workflow directly, and accept that the worst case is a fifteen-minute restore from the off-site backup. A site that takes money should not skip staging on a major release like 7.0.
What goes wrong during a major WordPress upgrade, and how do you spot it?
Three kinds of breakage. They show up in this order during a normal afternoon.
The first is a critical-error screen. WordPress shows a plain page that says "There has been a critical error on this website." Almost always a plugin that demanded a newer PHP version than the host runs. The fix is to switch the offending plugin off via the file system and roll it back from the backup.
The second is broken styling. The fonts look wrong. The header colors changed.
A block pattern saved with a 6.x theme renders the wrong way. This is the theme catching up to the 7.0 baseline. The fix is to refresh the page once with the cache cleared, then check the theme author’s site for a 7.0-ready release.
The third is a quiet feature break. The contact form submits a blank email. The newsletter signup posts to the wrong page.
The checkout hangs at the payment step. This is the most dangerous category because nobody notices until a real visitor reports it days later.
The smoke test after each step (homepage, contact form, one inner page, the login screen) catches the loud failures the same minute they happen. The quiet failures need a slower test: a real form submission, a test order, a real account login.
If your site collects money, run a one-cent test transaction on the staging copy after the upgrade. The hour spent on the test is cheaper than the lost sale you do not yet know about.
What can you safely leave for next month after the 7.0 upgrade?
The new AI features. WordPress 7.0 ships a new AI Client and a Connector’s screen for hooking AI services into wp-admin. It also ships a new dashboard look, new blocks, and a Command Palette.
None of this needs to be set up the day you upgrade. The AI Client is off until you turn it on. The dashboard works the same as before. The new blocks sit in the Inserter, waiting.
The first job after a clean upgrade is to confirm nothing broke. The second job is to write your next post the way you always have. The third job, the next quiet evening, is to learn the Command Palette.
The reading list for what changed in WordPress 7.0 lives in the small-business owner’s tour of WordPress 7.0. Read that after the upgrade is in, not before. The upgrade is the job. The features come later.
If something does break during the upgrade and the rollback is not obvious, the troubleshooting reference for WordPress covers the calm version of the bisection process. The plugin you just updated is the most likely suspect. The theme is the next most likely, and core itself is almost never the cause.
A small site running a clean plugin list and a maintained theme on a current PHP version is going to make it through the 7.0 upgrade without incident. The safe shape is the same shape it has always been.
Backup, then core, then themes, then plugins. One at a time, with a smoke test after each.
Other questions worth answering
How long should you wait before applying a brand-new core release like Armstrong?
There is no fixed number of days. WordPress 7.0 (Armstrong) shipped in May 2026, and its release notes on wordpress.org/news point to the Field Guide. Wait until you have tested your themes and plugins on a staging copy, with anything touching payments or e-commerce first. The rest can wait for a quiet evening, so read the Field Guide once those vendor updates start landing on your dashboard.
Does the Armstrong release affect WooCommerce stores differently than brochure shops?
Yes, payment and checkout flows feel a release more than brochure pages do. Hold off on the WooCommerce extension and any payment gateway extensions until you have tested them on a staging copy. Roll a one-cent test order through that copy before you trust live checkout. The small cost of testing beats a quiet checkout failure days later.
What does the new AI Client in Armstrong do once you switch it on?
The AI Client gives the wp-admin dashboard a small bridge to external AI services like OpenAI or Anthropic. A site owner wires it to one provider and uses it inside the block editor for draft assistance. The Client ships disabled by default in 7.0. You opt in from a Settings panel, paste an API key, and pick which providers the dashboard may call.
How would you roll back to a 6.x release if Armstrong breaks something later?
Two paths exist for a 6.x rollback. The first is a one-click rollback if your managed host offers it. The second is restoring from the off-site backup you took before applying 7.0. The UpdraftPlus archive on Google Drive or Dropbox holds the files and database snapshot you need.
What setup does the Command Palette need before it shows useful results?
Almost none. The Command Palette opens with Ctrl-K or Cmd-K from anywhere inside wp-admin and indexes posts, pages, settings, and block patterns the same minute. The new blocks that ship with 7.0 appear in the Inserter without configuration. Both features sit ready the moment the core update finishes.
Which check should you run first if you only have an hour for the 7.0 upgrade?
The PHP version. Two clicks in Site Health.
If PHP is 7.4 or higher, you have green light for the upgrade. Take the off-site backup, apply the core update, smoke-test, and you are done with the most critical step. The themes and plugins can wait for the next quiet evening.
If PHP is older than 7.4, the upgrade is on hold until PHP is updated. The host’s support channel is the right next call. Ask them to switch PHP to 8.1 or 8.2 on a quiet evening.
A small business site does not need to be the first on the block to run WordPress 7.0. It needs to make the upgrade without losing a single hour of revenue. Five steps, one at a time, with a backup at the start and a smoke test at the end of each.
Want a calm second opinion before you click the Update Now button, or help reading the Updates screen if it lists thirty pending changes after months of waiting? You can contact me here. Send me the PHP version your host shows and the list of pending plugin updates.
I will tell you which order to run them in and which ones want the staging detour. There is no pitch, no upsell, and the conversation is free.