An email arrives from your host: PHP 8.x will become the minimum on such-and-such a date. Or no email arrives, the change happens anyway, and the site breaks on a Tuesday.
A WordPress PHP version update is not optional and should not be resisted. Old PHP versions stop receiving security fixes, which makes running one a genuine risk rather than a conservative choice. Whether the change is routine or a bad afternoon depends entirely on what you do beforehand.
What PHP is, briefly
PHP is the language WordPress is written in, running on the server. Your host chooses which version is installed, and periodically retires old ones — as they must, because unsupported versions stop being patched.
Newer versions are also genuinely faster. The performance difference between an old PHP and a current one is one of the few upgrades that improves speed without any work on the site itself.
Check compatibility before the date, not after
Find out what you are running. To check PHP version WordPress reports it on the Site Health screen in WordPress shows your current PHP version and will warn you if it is outdated.
Check the plugins. The directory lists a “Requires PHP” value for each. What you are looking for is not plugins that require a high version — it is plugins that have not been updated in years, because those are the ones written for an older PHP with nobody left to adapt them. Those are covered in what to do about an abandoned WordPress plugin.
Check the theme, especially a custom one. A theme built years ago by a developer you no longer work with is the single most common source of trouble here, because nobody has looked at that code since it was written.
Run a compatibility scanner if you like, but treat it as a first pass. These tools produce false positives and miss dynamic code. A real test on a copy of the site is worth more than any report.
What actually breaks
Almost always old code using functions that newer PHP removed. In practice the symptoms are narrow and recognisable.
A blank white page, because a fatal error stopped the page rendering. Warnings appearing at the top of pages, which look alarming and are usually harmless. One specific feature failing while everything else works — a form, a slider, a payment integration. And occasionally the admin area failing while the front end continues to look fine, which is disorienting but easier to fix than the reverse.
How to move without downtime
- Update everything first. Current plugin and theme versions are far more likely to be compatible than versions from two years ago. Do this before touching PHP, not at the same time — changing two things at once makes any failure ambiguous.
- Take a backup and confirm you can restore it.
- Test on a copy. Most hosts let you set the PHP version per site, so a staging site can run the new version while the live site stays where it is. This is the whole answer, and it is the step people skip.
- Click through everything that matters on the copy — forms, checkout, login, admin screens, anything custom.
- Switch the live site at a quiet hour, then check the same list again. Most hosts let you switch back in one click if something is wrong, which makes this far less frightening than it sounds.
Why hosts do this, and why arguing is the wrong move
It helps to understand that the host is not being awkward. PHP versions have published end-of-life dates, after which they stop receiving security fixes. A host still running one is running unpatched software across every site on the server, which is a risk to all of them.
Some hosts allow you to stay on an old version for a while, occasionally for a fee. Taking that option is worth doing only as a short bridge while you fix the actual problem. As a permanent arrangement it means paying to stay exposed, and the underlying incompatibility does not improve with age u2014 it gets worse, because the plugin you are protecting keeps falling further behind.
The version that costs least is a compatibility check a month before the deadline, done calmly.
If it has already broken
Switch the PHP version back first. Get the site working, then diagnose calmly rather than under pressure — the point of rolling back is to remove the time limit.
Then turn on error logging and read what it actually says, rather than guessing. The log will usually name the file, which names the plugin or theme responsible. Our guide on why WordPress websites keep breaking covers reading that log.
Then fix the cause: update it, replace it, or have the code adapted. Staying on an unsupported PHP version is not a fix — it is a decision to run without security patches, which costs more later.
This is one of the changes that arrives on somebody else’s schedule, which is why knowing about it early matters. Managed WordPress maintenance is largely about noticing these before the deadline rather than after.