PHP end of life: what it means for your WordPress site
Short answer: PHP is the programming language WordPress runs on, and each PHP version gets security fixes for a limited time; after "end of life" it gets none. As of November 2026, php.net lists PHP 8.2 as receiving security fixes only until 31 December 2026, with 8.3, 8.4 and 8.5 supported longer, while WordPress.org recommends PHP 8.3 or greater. Check your current version, update WordPress, your theme and plugins, test the new PHP version on a staging copy, then switch live.
The host email usually sounds more urgent than the job is. For a well-maintained site, changing PHP is often a setting in the hosting panel and an afternoon of testing. For a site that hasn't been updated in years, it can expose old plugins that no longer work.
What "end of life" actually means
PHP's own supported-versions page explains the cycle: each release branch gets two years of active support (bug and security fixes), then two more years of fixes for critical security issues only. After those four years, the branch reaches end of life and "is no longer supported", and php.net warns that users may be exposed to unpatched security vulnerabilities.
Your site won't switch off on the end-of-life date. What changes:
- New security holes in that PHP version won't be fixed.
- Hosts usually stop offering old versions eventually, or start charging for extended support. Read your host's email for their dates.
- New plugin and theme versions gradually stop supporting old PHP, so you can't update them either.
Supported PHP versions as of November 2026
From php.net's supported-versions page:
| PHP branch | Active support until | Security fixes until |
|---|---|---|
| 8.2 | 31 Dec 2024 | 31 Dec 2026 |
| 8.3 | 31 Dec 2025 | 31 Dec 2027 |
| 8.4 | 31 Dec 2026 | 31 Dec 2028 |
| 8.5 | 31 Dec 2027 | 31 Dec 2029 |
Anything older than 8.2 is already past end of life.
What WordPress supports
WordPress.org's requirements page recommends PHP 8.3 or greater. It notes WordPress still works with PHP 7.4+ in legacy environments, but that those versions have reached end of life and may expose your site to vulnerabilities.
The core team's compatibility table (last updated August 2026) shows recent WordPress versions, including 7.0 and 7.1, marked compatible with PHP 7.4 through 8.5, and records that WordPress 7.0 dropped support for PHP 7.2 and 7.3. WordPress core usually isn't the problem; old plugins and themes are.
Check your current version
- In the WordPress dashboard, go to Tools → Site Health → Info. The WordPress documentation describes this tab as a detailed view of your site's technical setup, including the Server section where the PHP version is shown.
- Or check your hosting control panel, usually under a "PHP version" or "PHP settings" option.
- Note the version, and whether your host runs different versions per site.
While you're in Site Health, look at the Status tab too. It often flags outdated PHP and other issues worth fixing at the same time.
Upgrade steps
1. Take a full backup
Files and database, stored somewhere other than the server. Confirm you know how to restore it.
2. Update everything else first
Update WordPress core, then your theme, then all plugins, on the current PHP version. Many compatibility fixes arrive in plugin updates. Delete plugins and themes you no longer use; they can still cause errors.
3. Look for abandoned plugins
Check each plugin's page on wordpress.org: when was it last updated, and is it tested with recent WordPress versions? A plugin untouched for years is the most likely to break on new PHP. Plan a replacement before the upgrade, not after.
4. Test on staging
Create a staging copy (most hosts offer one), switch staging to the new PHP version, and test:
- [ ] home page and main service pages
- [ ] contact and booking forms, including the notification emails
- [ ] checkout and payments in test mode, if you run a shop
- [ ] logging in to the dashboard, editing and saving a page
- [ ] page-builder layouts and sliders
- [ ] anything scheduled: backups, reminders, feeds
Turn on error logging on staging (not live) so warnings show up. "Deprecated" notices are early warnings; "fatal errors" are what break pages.
5. Choose the target version
Jump to a version with a long runway if your plugins allow it. Moving from 8.1 to 8.2 now only buys you until the end of 2026. If something critical won't run on 8.3 or newer yet, upgrade as far as you safely can and set a date to replace that plugin.
6. Switch live, then check
Change the PHP version on live during a quiet hour, clear caches, and repeat the key tests. Keep the previous version in mind: on most hosts you can switch back in the panel if something breaks badly, then fix it on staging.
When it gets complicated
Expect more work if:
- the site uses a custom theme or plugin written years ago
- a premium plugin license expired, so you can't get the compatible version
- the site runs on an old page builder that's no longer maintained
- WordPress itself hasn't been updated for a long time
In those cases, the PHP upgrade is the moment to decide whether to repair, replace parts, or rebuild.
FAQ
Will upgrading PHP make my site faster?
Newer PHP versions often perform better, but the difference depends on your site and hosting. Treat speed as a bonus, not the reason.
Can I just ignore the host's email?
Not for long. Your site stays exposed to unfixed PHP vulnerabilities, and hosts typically move accounts to newer versions or charge for extended support. Better to upgrade on your schedule than theirs.
Which PHP version should I pick?
The newest one your theme and plugins support on staging, ideally 8.3 or above, in line with WordPress.org's recommendation.
Do I need a developer for this?
For an up-to-date site, often not. If staging shows errors from a custom theme or plugin, a developer can usually fix or replace the problem code.
If your host's PHP deadline is coming and you'd like the upgrade tested properly first, send us your site address and current version.