Updating PHP on a WordPress Site: How to Do It Without Breaking Anything

Last week's critical PHP vulnerabilities sent a lot of WordPress owners to their hosting panel for the first time in years. The panel has a dropdown called "PHP version". It looks like the whole job. It isn't.

Switching the dropdown takes ten seconds. The work is everything that decides whether the site is still standing ten seconds later: the plugins, the theme, the bits of custom code someone added in 2019 and forgot. This is the order we follow when we do it for clients, the traps that catch most sites, and when it's fine to do it yourself.

Pick the version first

WordPress recommends PHP 8.3 or newer, and the core team's compatibility table marks WordPress 6.7 and up as working on 8.3 and 8.4, with 8.5 supported from WordPress 6.9.

Our advice: go to 8.4. Not 8.2, because it stops getting security fixes on 31 December 2026 and you'd be doing this again in two months. Not 8.5 yet, unless every plugin you rely on explicitly says it's ready. 8.4 gets security updates until the end of 2028.

If you run WooCommerce: its official minimum is still PHP 7.4, but the team recommends 8.3 or newer and is raising the floor. The shop itself is not the problem. Its payment and shipping extensions are, and we'll get to those.

Step 1: a backup you have actually restored

Everyone has a backup. Far fewer people have ever restored one. Before anything else, take a full copy, files and database, and restore it somewhere, even if only to a staging copy on the same host. If the restore works, you have a safety net. If it doesn't, you've just learned that at the cheapest possible moment.

Step 2: update everything while you're still on the old PHP

Counterintuitive, but important. Update WordPress core, the theme and every plugin first, on the PHP version you have now. The fixes that make a plugin work on PHP 8 live in its newer releases. If you switch PHP first and then update plugins, you're debugging two changes at once and won't know which one broke the checkout.

Two things will surface at this step, and both are good to know early:

• Plugins that can't be updated. Premium plugins with an expired licence, or ones bought as a one-off from a marketplace years ago. They'll show "update available" with no button, or no update at all.
• Plugins that are abandoned. Open each one on wordpress.org. If the last update was two or more years ago and it says "untested with your version of WordPress", treat it as a risk.

Step 3: find what will break before it breaks

Make a list of everything that isn't WordPress itself: plugins, the theme, a child theme if there is one, and any custom code in functions.php or a "code snippets" plugin. For each item, answer one question: has it been updated in the last year?

Then look at what the site actually does. Write down the five flows that matter for yours. For a company site: the home page, the page that brings in enquiries, the contact form, the blog, logging into the admin. For a shop: add the product page and checkout. For a booking or membership site: the booking form and the member login. Those are what you'll test.

There's a plugin called PHP Compatibility Checker that scans code for known problems. It's worth running, but it misses a lot and flags things that are fine, so treat it as a hint, not a verdict. The real test is step 4.

Here's what catches most sites, in rough order of how often we see it:

Step 4: switch PHP on a copy, not on the live site

Most hosts offer a staging copy with one click: SiteGround, Kinsta, WP Engine, Cloudways, Hostinger and others. If yours doesn't, a developer can make one in an hour. Do not skip this because the site is small. Small sites have the oldest plugins.

On the copy:

1. Switch PHP to 8.4.
2. Turn on WordPress debug logging, so problems go to a file instead of the screen.
3. Walk through the five flows you wrote down. Submit the contact form and check the email arrives. For a shop, place a test order with a test card.
4. Open the admin: the dashboard, the plugin list, the page editor, the orders screen.
5. Read the debug log. Lines marked Fatal must be fixed. Lines marked Deprecated are warnings about things that will break in a future version; note them, they're not urgent.

If something fails, you now know what, and you fix it on the copy where nobody can see. This step is where almost all the hours in an upgrade go.

Step 5: switch live, then watch

When the copy passes:

1. Pick a quiet hour and tell whoever handles customer messages.
2. Take a fresh backup.
3. Switch PHP in the panel.
4. Clear every cache: the caching plugin, the host's cache, the CDN if you have one. Old cached pages can hide both problems and fixes.
5. Run the same five flows on the live site.
6. Keep the debug log on for a day and read it once.

Switching PHP is reversible: if something unexpected appears, switch back while you look. That's the one advantage of this job over most changes, so keep the old version available in the panel for a week rather than letting the host remove it.

When to do it yourself and when not to

A brochure site with a maintained theme and under ten plugins, all updated this year, is a reasonable afternoon for a careful owner: backup, copy, switch, click through, switch live.

A shop, a membership or booking site, anything with payments, a page builder, a custom theme, or more than twenty plugins is a developer job. Not because the steps are different, but because the fixing in step 4 needs someone who can read the error and change the code.

At our rate of $40 an hour, a WordPress upgrade takes 6 to 16 hours, $240 to $640: the copy, the switch, testing every flow, replacing or fixing what breaks, the live switch and a day of watching. The low end is a company site with a maintained theme and a dozen plugins; the high end is a WooCommerce shop with a page builder and forty. If the theme itself has to be fixed or replaced, that's a separate quote, and we'll tell you before starting.

What you should have at the end

Not just a site on PHP 8.4. You should also have a staging copy that stays, so the next PHP release is an hour of testing instead of a week of worry; a short list of plugins that were replaced and why; and a note of which host setting controls PHP, so nobody has to rediscover it.

If you'd like us to look before you touch anything, send the site address below. We'll tell you what version it runs, which plugins look risky, and what the upgrade would take.