Outdated PHP Version: Why Your Host Keeps Warning You
By CodexierPublished 5 min read
Hosts send the same email every year: your site runs a PHP version that is no longer supported, please update. Site owners ignore it because the site works and a previous update once broke something. Both reactions are understandable and both are wrong. This guide explains what end-of-life means, what actually breaks during an upgrade, and the staging-first routine that makes the switch boring.
What PHP end-of-life means
PHP is the language WordPress, WooCommerce and most CMS platforms run on. The PHP project publishes a support schedule: after roughly three years a version stops receiving any fixes. From that day, any vulnerability found in the language runtime stays open on every server still running it. Your host cannot patch it for you, and the warning is their way of saying so.
Security and speed effects
| Aspect | On an end-of-life version | After upgrading |
|---|---|---|
| Security fixes | None; known issues stay open | Regular patches from the PHP project |
| Page speed | Slower runtime, more server time per request | Faster execution, often visibly quicker pages |
| Plugin updates | Newer plugin releases refuse to install | Full access to current plugin versions |
| Host support | Version scheduled for removal; surcharge on some hosts | Standard, supported configuration |
Plugin authors drop old PHP versions too. Staying behind eventually freezes your whole plugin stack at old, unpatched releases.
The speed effect is worth stating plainly: two major versions of PHP can be the difference between a page that renders in under a second and one that takes two. For an online shop that is checkout conversions; for any site it is a ranking factor.
Compatibility checks for themes and plugins
An upgrade breaks code that relies on features later versions removed. The usual culprits are a custom theme built years ago, an abandoned plugin, and snippets someone pasted into functions.php.
- List every plugin with its last update date. Anything not updated in over a year is a candidate for replacement rather than testing.
- Check each plugin's stated PHP compatibility on its listing; most current ones declare it.
- Run a compatibility scanner across the theme and custom code to flag removed functions before you switch.
- Note what the site actually uses: forms, shop, booking, membership. Those flows are what you test by hand afterwards.
Testing on staging
Never change the PHP version on the live site first. Most hosts offer a staging copy in one click; if yours does not, a subdomain copy does the same job.
- Take a full backup of files and database, and confirm it restores. This is the rollback.
- Create the staging copy, switch it to the target PHP version and turn on error logging.
- Walk through the site as a visitor and as an admin: front page, forms, checkout or booking, admin screens, media upload.
- Fix what the log shows: update the plugin, replace it, or patch the custom code. Repeat until the log is clean.
- Only when staging is clean, schedule the production switch for a quiet hour.
This is the routine included in our performance and security optimisation service, which also takes the opportunity to fix speed and hardening issues while the site is on staging. Prices are on the pricing page.
Switching and rolling back
Switch
Change the version in the hosting panel, clear all caches, and run the same walk-through on production immediately. Keep the old version selectable.
Watch
Check error logs and form submissions for the next day. Problems that only appear under real traffic show up here, not on staging.
Roll back
If something serious fails, switch the version back in the panel first, then restore the backup if needed. Rolling back the version takes a minute; the backup is the second line.
When you do not need help with this
If your site is a standard theme with a handful of current plugins and your host offers one-click staging, do it yourself in an afternoon following the steps above. If your host has already moved you to a supported version and nothing broke, you are done; just keep plugins current. Help is worth paying for when the theme is custom, the plugin list is long or abandoned, or the site takes orders and an hour of downtime costs real money. If that is you, a 15-minute call is enough to scope it, and a monthly maintenance package prevents the next warning email. For the wider picture, see the risks of running an old website.
Frequently asked questions
Which PHP version should we upgrade to?
The newest version your plugins and theme support, which is usually the current stable release or the one before it. Check the PHP project's support schedule and pick a version with at least two years of security support left, so you are not doing this again next year.
Will upgrading PHP break WordPress?
WordPress core itself supports current PHP versions promptly. What breaks is old theme code, abandoned plugins and custom snippets. Testing on staging finds them before your visitors do, and the fix is usually updating or replacing one or two plugins.
Our developer is gone and the theme is custom. What then?
Run the staging test anyway; a custom theme often needs only small fixes. If the errors are extensive, weigh the cost of patching an unmaintained theme against replacing it with a maintained one, since the same problem returns at the next PHP version.
Got the warning email and not sure what will break?
Send us the site address and your plugin list before a short call. We tell you which plugins are at risk, whether staging is available on your host, and what a fixed-price upgrade with speed and security fixes would cost.
Book a free 15-minute call