PHP 8.2 End of Life: How to Upgrade WordPress Safely

What "end of life" actually means

Every version of PHP gets about four years of support. For the first two, it gets bug fixes and security fixes. For the last two, it gets security fixes only. Then it reaches end of life, and the PHP project stops fixing it completely.

Your website doesn't stop working on 1 January 2027. Nothing switches off. The risk is quieter than that: the next time a serious flaw is found, every supported version gets a fix and yours doesn't. Your site keeps running, with a known hole in it.

We saw exactly how fast that can matter in October 2026, when details of a critical flaw leaked online and attack attempts started within a day. The sites that were fine were the ones on a supported version, with a host that updated it.

The dates that matter

These come straight from the PHP project's official supported versions page:

• PHP 8.1 and older: already end of life. No more fixes since 31 December 2025.
• PHP 8.2: security fixes until 31 December 2026.
• PHP 8.3: security fixes until 31 December 2027.
• PHP 8.4: security fixes until 31 December 2028.
• PHP 8.5: security fixes until 31 December 2029.

If your site is on 8.1 or 8.2, the upgrade is due now. Not because something breaks on New Year's Day, but because you want to choose the timing, not have a security incident choose it for you.

Which version to move to

For most WordPress sites I'd move to PHP 8.4. It's been out since November 2024, so themes and plugins have had time to catch up, and it's supported until the end of 2028.

• PHP 8.3 is the safest small step, and it's the minimum WordPress currently recommends. But it only buys you one more year before you do this again.
• PHP 8.4 is the sweet spot: mature, widely supported by hosts and plugins, and good for two more years.
• PHP 8.5 gives you the longest runway (to the end of 2029). It's the right choice if your plugins already support it; check before you commit.

What can break

WordPress itself handles new PHP versions well. Problems almost always come from themes and plugins, especially ones that haven't been updated in a few years. In practice, I see three kinds of trouble:

1. Abandoned plugins. A plugin last updated in 2021 was never tested on PHP 8.4. It might be fine. It might show errors or stop working. These are the first thing to check.
2. Missing extensions. PHP 8.4 removed a few rarely used extensions from the core package, including IMAP, which some older email and help-desk plugins rely on to read a mailbox. Your host can usually still install it, but you need to know you need it.
3. Deprecation notices. Each new version warns about older ways of writing code that will stop working in a future version. PHP 8.4, for example, deprecated a common way of declaring optional parameters. These are warnings, not errors, and they don't break your site, but they can fill up error logs or show up on screen if your site is set to display errors.

The good news: on a well-maintained site with updated plugins, the most common result of a PHP upgrade is nothing at all, except a site that's often a little faster.

The upgrade plan, step by step

1. Check your current version. In WordPress, go to Tools, then Site Health, then Info, and open Server. My PHP2Shell explainer has a picture of exactly where to look.
2. Take a full backup. Files and database, stored somewhere other than the server itself. Check you can actually download it.
3. Update everything first. WordPress, your theme and every plugin. Updates often include the compatibility fixes you need.
4. Review your plugin list. For each plugin, look at when it was last updated on its page in the WordPress plugin directory. Anything not updated in over a year is a risk; replace it or remove it if you can.
5. Test on a staging copy. Many hosts offer one-click staging. Switch the staging site to PHP 8.4 in your hosting panel (look for "PHP Version", "PHP Configuration" or "MultiPHP Manager") and click through everything that matters.
6. Turn on error logging while you test, so you see problems that don't show on screen. Add this to wp-config.php on the staging site:

// Log PHP errors to wp-content/debug.log without showing them to visitors
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Then test the parts of the site that make you money or bring in enquiries:

• Every contact and quote form, all the way to the inbox.
• Checkout, payments and order emails, if you run a shop.
• Logging in, editing a page, and uploading an image in the admin.
• Any booking, membership or search feature.
• The homepage and your most visited pages on a phone.

Then read wp-content/debug.log. Lines marked "Fatal error" need fixing before you go live. Lines marked "Deprecated" can usually wait, but note which plugin they come from.

7. Switch the live site at a quiet time, using the same setting in your hosting panel.
8. Test the important pages again, live, the same way.
9. Watch for a couple of days. Check your error log, form submissions and orders, and run the site through my free Website QA tool to catch anything visible.

If something breaks

This is the part that makes PHP upgrades low-risk: on most hosting, rolling back is the same setting you just changed. Switch the PHP version back, and the site is back to how it was within a minute or two. Your content isn't touched by a PHP change.

Then work out which plugin caused it (the error log usually names it), update or replace it on staging, and try again. Rolling back buys time; it isn't a place to stay, because the 31 December deadline doesn't move.

What it costs

On a typical small business site with maintained plugins, the upgrade itself is a setting your host can change in minutes, and the testing takes an hour or two. Most of the cost, when there is one, comes from replacing an abandoned plugin or fixing a custom theme written years ago.

That's also why it's worth doing before December rather than in it: you have time to replace a plugin properly instead of in a hurry.

Wrapping up

PHP 8.2's end of life on 31 December 2026 isn't an emergency, but it is a deadline. Back up, update everything, test PHP 8.4 on a staging copy, switch the live site, and keep an eye on it for a few days.

If you'd rather not do it yourself, this is exactly the kind of job I take on for clients. Get in touch and I'll check your site and handle the upgrade.

Sources

• PHP: Supported Versions, for every end-of-life date in this post.
• WordPress requirements, which recommend PHP 8.3 or newer.
• PHP RFC: unbundle IMAP, Pspell and OCI8, the extensions removed from core in PHP 8.4.

Keep reading