The two warnings
One comes from your hosting company: "Your site is running PHP 7.4, which is no longer supported. Please upgrade." The other is at the top of the WordPress dashboard: "WordPress 6.x is available. Please update now." Both have been there for a while. Nobody has clicked, because the last time someone clicked, something broke.
The warnings are right, and the fear is reasonable. Here is what each means and how to act on both without a bad afternoon.
What PHP is and why the version matters
PHP is the programming language WordPress is written in. Your host runs a particular version of it. Each version gets security fixes for about three years, after which it is unsupported: any vulnerability found from then on is never patched.
Running an unsupported PHP version means:
- Security. Known holes stay open. Attackers scan for old versions specifically.
- Speed. Each major PHP version has been faster than the last. Moving from 7.4 to 8.3 alone often cuts server processing time by a third or more, for free.
- Compatibility. Plugin and theme authors test on current versions. Older PHP increasingly means plugins that will not update, or will not work when they do.
- Hosting. Hosts eventually remove old versions. When they do, the site either breaks or is force-migrated without you.
What WordPress versions mean
WordPress releases major versions a few times a year and security releases in between. Minor security updates apply automatically on most sites. Major updates usually require a click.
An out-of-date WordPress core means missing security fixes and, over time, plugins that require a newer core and stop updating. Two versions behind is worth fixing soon. Several versions behind is a risk.
Why updates break things
Both updates change the environment the theme and plugins run in. A plugin written for PHP 7 may use a function removed in PHP 8. A theme written for WordPress 5 may rely on behaviour changed in 6. The plugin or theme that breaks is nearly always one that has not itself been updated in years, because its author fixed the problem long ago in a version you do not have.
So the failure is not really the PHP or WordPress update. It is the old plugin or theme it exposes.
The safe order
1. Take a full backup and confirm you know how to restore it. Files and database. Note the time.
2. Make a staging copy. Everything below happens there first.
3. Update plugins and themes first, on staging. Every plugin, every theme, to their latest versions. This is the counterintuitive step: bring the plugins up to date before changing the environment they run in, because their newer versions are the ones that support the newer PHP and WordPress. Check the site after.
4. Look for abandoned plugins. Any plugin whose last update was more than two years ago, or whose plugin page says it has not been tested with recent WordPress versions, is a candidate to break. Decide now: find a maintained replacement, or accept the risk and test it carefully.
5. Update WordPress core, on staging. Check the site. Front end, admin, forms, booking, checkout if you have one.
6. Change the PHP version, on staging. Most hosts let you pick the version per site in the control panel. Go to the current supported version, not the newest bleeding-edge release. Check the site again, thoroughly. Turn on the error log and read it; PHP deprecation warnings that do not break the site now will break it at the next version.
7. Fix what broke. Typically one or two plugins with PHP errors. Replace or update them. If the theme throws errors, a small fix from a developer is usually enough; if it throws many, the theme is the abandoned component.
8. Repeat on live, in the same order, at a quiet time, with the backup from step one ready. Plugins and themes, then core, then PHP. Check after each.
9. Watch for a week. Error log, forms, anything scheduled. Fix stragglers.
What if you cannot use staging
If your host has no staging and you cannot make a copy, the order still holds, with more caution: back up, update plugins and themes one small group at a time checking after each, then core, then PHP, at the quietest time you have, with the backup ready to restore. And plan to move to a host that offers staging, because this will come round again.
The time it takes
A well-maintained site: an hour, mostly waiting for updates. A site three years behind with a page builder and twenty plugins: half a day, with one or two plugins replaced. A site with a custom theme written for PHP 5: a developer job, and possibly the moment to decide whether the theme is worth keeping.
After
Turn on automatic minor updates for WordPress if they are off. Set a monthly routine for plugin updates, on staging. Check the PHP version once a year against your host's supported list. That routine is the whole point of a care plan: the updates become small, frequent and boring rather than rare and frightening. If you are staring at both warnings now and the site has not been touched in a year, a diagnosis tells you which plugins will survive the update before you start, which is the part most people wish they had known.