What happens to a WordPress site when the host upgrades PHP?
Usually nothing you can see. WordPress itself supports every PHP version from 7.4 to 8.5, so the risk sits in old plugins, themes and custom code, and the worst failures are the quiet ones: a contact form that still says "thank you" while the enquiry never reaches your CRM.
- Before the switch: take a backup you have tested restoring, update everything, and check which plugins have not been updated in years
- After the switch: submit your own enquiry form and confirm it lands in the CRM, then test checkout, logins and scheduled emails
- If something breaks: use the recovery mode email WordPress sends, pause the failing plugin, and only switch PHP back as a stopgap
What changed since this was first written
The 2022 version of this article was about one host moving its servers to PHP 5.4. That version has been out of support for over a decade, and WordPress now refuses to run on anything older than PHP 7.4.
What has not changed is the shape of the problem. Your host decides when the PHP version under your site changes, the notice is easy to miss, and the parts that break are rarely the parts anyone checks.
Why hosts are moving sites now
PHP 8.2 stops receiving security fixes on 31 December 2026. Hosts do not want to run unsupported software, so sites still on 8.2 or older are being moved, and the notices go out in the weeks before.
| PHP version | Security fixes until | Runs WordPress 7.1 | What it means for you |
|---|---|---|---|
| 7.4 to 8.1 | Already ended | Yes | The site works, but the server no longer gets security fixes. Expect your host to move you |
| 8.2 | 31 December 2026 | Yes | Plan the move now rather than in the last week of December |
| 8.3 | 31 December 2027 | Yes | The minimum WordPress.org recommends today |
| 8.4 | 31 December 2028 | Yes | A sensible target for most sites |
| 8.5 | 31 December 2029 | Yes | The newest; check your oldest plugins first |
Support dates come from the PHP supported versions page. Compatibility comes from the WordPress core handbook's PHP compatibility table, and the recommendation from the WordPress requirements page. All three were checked on 17 October 2026, when the current release was WordPress 7.1.3.
What actually breaks, and how you would notice
Each new PHP version removes functions that were marked as deprecated in the one before. Code written for an older version calls one of them, and PHP stops. Whether you notice depends entirely on where that code runs.
| Part of the site | How it fails | How you would notice |
|---|---|---|
| WordPress core | Rarely, if it is kept updated | An outdated core version is the warning sign, not an error |
| An abandoned plugin | A fatal error on the pages that load it | A blank page or an error message, and a recovery mode email to the admin address |
| Theme or custom code snippets | Broken layout or a fatal error across the site | Visible straight away, usually by a visitor before you |
| Contact form to CRM connection | The form submits, the hand-off to the CRM fails | Nobody notices until someone asks why the leads stopped |
| Payments and webhooks | Orders complete but confirmations or stock updates do not | Customer complaints, or numbers that stop matching |
| Scheduled tasks | Backups, reminder emails and imports stop running | Weeks later, when you need the backup |
The bottom three rows are the reason this deserves an hour of attention. A broken page gets reported. A broken connection between your site and the rest of your business does not, which is why connecting WordPress to a CRM is worth doing in a way that tells you when it fails.
Before your host switches the version
- Find your current version. In the dashboard, go to Tools, then Site Health, then the Info tab, and open the Server section.
- Take a backup and test restoring it. A backup nobody has restored is a hope, not a plan.
- Update core, plugins and theme. Many PHP problems are already fixed in a newer release of the plugin that causes them.
- List the plugins nobody maintains. On each plugin's WordPress.org page, check when it was last updated and which PHP version it says it needs. Anything untouched for years is your likeliest failure.
- Test on a copy if your host offers staging. Switch the copy to the new version first and click through the pages that matter.
Themes deserve the same check, because a theme that bundles its own plugins ties you to whoever maintains it. How to choose a WordPress theme covers what to look for before you buy.
After the switch: test what makes you money
Loading the home page proves very little. Test the paths that carry a customer from interest to a record in your systems, in the order they matter to you.
- Submit your own contact form and confirm the enquiry appears in the CRM with every field filled
- Place a test order or booking and check the confirmation email and the record it creates
- Log in as an editor and a customer, if your site has accounts
- Check the next scheduled backup and any automated email actually ran
These are the same end-to-end checks a new site needs, and the WordPress website launch checklist sets them out in full. Running them again after every PHP change is a short job, and it is the step most often skipped.
If something breaks
Since WordPress 5.2, a fatal error triggers an email to the admin address with a link into recovery mode. That mode pauses the failing plugin or theme for you, so you can log in and deal with it instead of staring at a blank screen.
From there, update the plugin if a newer version exists, or replace it if it is abandoned. If you cannot find the cause, deactivate all plugins and switch to a default theme, then reactivate them one at a time until the error returns.
If your host's control panel lets you choose the PHP version, switching back buys a few days. It is not a fix, because the older version is the one losing security support.
Where AI helps, and where it does not
An AI assistant is genuinely useful here. Paste in the fatal error from the log and it will usually name the deprecated function and the line that calls it, which turns a vague outage into a specific fix.
It cannot tell you whether an abandoned plugin's author will ever release a patch, and it cannot test your enquiry path for you. Those are decisions about your own site, and they still need someone to own them.
If the site is also running custom PHP beyond WordPress, the same support dates apply to its framework. How Laravel, CodeIgniter and CakePHP compare sets out how long each one stays supported. If you are planning a new build rather than an upgrade, which PHP version a new project should start on is covered alongside the choice between PHP, Node.js and Python.
Common questions
Which PHP version should a WordPress site run?
PHP 8.3 or newer, which is what WordPress.org recommends. PHP 8.4 receives security fixes until 31 December 2028, which makes it a sensible target for most sites.
Will a PHP upgrade break my WordPress site?
WordPress itself rarely breaks, because the current release supports PHP 7.4 to 8.5. The risk is in old plugins, themes and custom code, so update everything first and test the forms and checkout afterwards.
How do I check which PHP version my site uses?
In the WordPress dashboard, go to Tools, then Site Health, then the Info tab, and open the Server section. Your host's control panel usually shows it too.
Can I stay on an old PHP version?
WordPress still runs on PHP 7.4, but versions 8.1 and older no longer receive security fixes, and PHP 8.2 stops on 31 December 2026. Staying put leaves the server unpatched, and most hosts will move you anyway.
Can you check that our forms still reach the CRM after an upgrade?
Yes. Connecting websites to CRMs and making sure every enquiry arrives is part of our CRM setup and management work. Each project is quoted once the scope is clear (our answers page explains why), so tell us what your site connects to and we will tell you what to test.
