WordPress and PHP Versions: Upgrading Without Taking the Site Down

Changing the PHP version on a well maintained WordPress site is usually uneventful. Changing it on a site that has not been updated for a few years is one of the more reliable ways to take that site offline, and the failure is rarely graceful. This article covers what actually breaks, why, and the order of operations that avoids it.

What the failure looks like

Not a warning. A white screen, or a critical error message, on the whole site or on the admin area. That is because PHP removes deprecated behaviour at major versions, and code that used a removed feature does not degrade, it stops.

The awkward variant is a site that appears to survive the change and then fails later, because the code that breaks lives on a page nobody visited on the day. Checkout, a contact form, a specific admin screen or a scheduled job are common places for that to hide.

We have taken sites offline this way while doing what looked like routine maintenance. It is a genuine risk rather than a theoretical one, and the sites that suffered were, in every case, sites carrying plugins or themes that had not been updated in years.

What breaks, in order of likelihood

Abandoned plugins. By a wide margin the most common cause. A plugin whose author stopped work five years ago was written against a PHP version that no longer behaves the same way. It is not going to be fixed, and no amount of care on your part changes that.

Commercial themes bought once and never updated. The same problem with an additional complication: theme licences often include updates only for a period, so the fixed version may exist but be behind a renewal you let lapse.

Custom code in the theme. Snippets added to functions.php over the years, often copied from a forum answer, are rarely revisited and rarely tested against anything.

WordPress itself. Realistically the least likely of the four. WordPress core is careful about compatibility and current versions support current PHP. If core is your problem, it is because core is very old, which is a more urgent problem than the PHP version anyway.

The order that works

The instinct is to change the PHP version and then fix what breaks. Do it the other way round.

1. Take a backup you have actually tested. Not “there is a backup somewhere”. One you know how to restore.
2. Update WordPress, then themes, then plugins, on the PHP version that currently works. A current plugin is far more likely to tolerate a newer PHP than the version you have. Doing this first also means that if something breaks, you know it was the update rather than the PHP change.
3. Deal with anything that will not update. Inventory what has not seen a release in two or more years. For each, decide whether to replace it, pay for a renewed licence, or accept it as the reason you cannot move. Doing this now, deliberately, is much better than discovering it during an outage.
4. Test on a copy. Take a staging copy, set the newer PHP version on it, and click through the site properly: the front page, a few posts or products, the checkout if there is one, every form that sends email, and the admin area including the plugin screens.
5. Read the error log, not just the pages. A staging site can look perfectly healthy while filling the log with deprecation notices that point straight at what will fail next.
6. Change the live site, then look again. Same list. Deliberately, not just the home page.

Two practical notes

The version is per account. On our hosting you choose the PHP version for your account, so you are not waiting for us to move a whole server and we are not moving you without warning. If more than one application shares an account, though, they share the PHP version too, and the least tolerant one sets the ceiling for all of them. That is worth knowing before it becomes a surprise.

Being on an older version is not an emergency. Our older PHP builds continue to receive backported security fixes, so a site that has to stay put for a while is not unpatched. The reason to move is that the software you run will eventually require a newer PHP, and newer PHP is meaningfully faster. Move deliberately rather than in a hurry.

If it has already gone wrong

Set the PHP version back to what it was. The site will usually return immediately, because nothing has been damaged; the code simply could not run. Then work through the steps above with the pressure off.

If you would like a staging copy to test an upgrade against, or you want us to look at which of your plugins are likely to be a problem, open a ticket and we will go through it with you.