PHP 8.2 reaches end of life on 31 December 2026, and most WordPress sites are not ready

The dates that matter

PHP publishes its own support schedule, and it is not negotiable. Each release gets roughly two years of active support with bug fixes, then roughly two years of security-only patches, then nothing.

Confirm these against php.net's supported versions page before you plan around them, because the schedule is occasionally adjusted and this article is a snapshot taken in October 2026.

Two practical readings of that table. If you are on 8.2, you have under twelve weeks before your language runtime stops receiving security fixes. If you are on anything below 8.2, that already happened and the question is how quickly you can move, not whether to.

WordPress itself has moved too. WordPress 7.0 dropped support for PHP 7.2 and 7.3, and the recommended version is 8.3. WordPress deliberately keeps supporting older PHP for backward compatibility, which is exactly why so many sites sit on unsupported versions: nothing visibly breaks, so nobody looks.

What end of life actually means

It does not mean your site stops working. On 1 January your site will load exactly as it did on 31 December, which is precisely why this gets ignored.

What it means is that from that date, a newly discovered vulnerability in PHP itself is never fixed on your version. Not slowly, not eventually. The fix exists for supported versions and your server does not receive it.

• No security patches. A remote code execution flaw in the runtime stays open.
• No bug fixes. Already true for 8.2 since the end of 2024.
• Plugins start dropping you. Maintainers set a minimum, and once a version is dead it becomes the obvious floor to raise.
• Compliance and insurance questions. If you hold personal or payment data, running an unsupported runtime is difficult to defend in an assessment or after an incident.
• You lose the performance. Each version has been meaningfully faster. Staying put costs speed you have already paid for.

The security point is the one that matters commercially. Most WordPress compromises arrive through a known vulnerability in an outdated component, as covered in fixing a hacked WordPress site. An unsupported PHP runtime is the largest possible version of that problem, because it sits underneath everything else.

Check what you are running, in thirty seconds

Do this now, before reading the rest. The answer changes what you need to do.

In the WordPress admin

Go to Tools, then Site Health, then the Info tab, and open the Server section. The PHP version is listed there. Site Health will also warn you directly if the version is outdated.

With WP-CLI

wp eval 'echo PHP_VERSION, PHP_EOL;'

# what the CLI itself is running on, which can differ from the web server
php -v

Those two can genuinely disagree. A host may run one version for web requests and another for command line and cron, which is how a site passes every check and still fails on a scheduled task. Check both.

Without any access

Create a file with <?php phpinfo();, load it, read the version, then delete it immediately. It exposes a great deal about your server and should never be left in place. Your host's control panel is the better route, and it is where you change the version anyway.

Testing compatibility before you touch anything

The upgrade itself is a dropdown in your hosting panel. The work is finding out what will break first.

1. Check your plugins and theme declare support

# list everything with its version and status
wp plugin list --fields=name,status,version,update
wp theme list --fields=name,status,version,update

# anything not updated in a long time is the risk
wp plugin list --field=name --status=active

For each active plugin, look at its page on WordPress.org and read Tested up to and Requires PHP. A plugin last updated three years ago is the thing most likely to break, and it is also a security problem on its own terms.

2. Scan the code for incompatibilities

PHP_CodeSniffer with the PHPCompatibility standard reports code that will not run on a target version. Run it against your theme and any custom plugin, which is where the real risk lives.

composer global require phpcompatibility/php-compatibility
phpcs -p ./wp-content/themes/your-theme \
  --standard=PHPCompatibility --runtime-set testVersion 8.4 \
  --extensions=php --report=summary

Read errors, not warnings. Deprecation warnings are normal, extremely common across the plugin ecosystem, and do not stop a site working.

3. Turn on logging and watch a real staging copy

// wp-config.php on staging only
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Then switch staging to the target version, use the site properly for an hour, and read wp-content/debug.log. Fatal errors are blockers. Deprecated notices are noise you can file for later.

Use the site properly is the operative part. Load the homepage and you will learn nothing. Place an order, submit the contact form, run a report, process a return, log in as a customer. Breakages concentrate in the paths nobody visits during a smoke test.

Upgrading safely

1. Take a full backup, files and database, and confirm you can actually restore it. An untested backup is a hope.
2. Update WordPress core, plugins and theme first. Most compatibility fixes already exist upstream; you just have not taken them. Do this before changing PHP, not at the same time, so you know which change caused what.
3. Clone to staging and switch the clone to the target version.
4. Exercise the real journeys and read the log.
5. Fix or replace what fails. An abandoned plugin is a replacement decision, not a patching one.
6. Switch production, during quiet hours, with the rollback path known before you start.
7. Watch the error log for 48 hours. Scheduled tasks and monthly jobs surface later than page loads.

Pick 8.4 rather than 8.3 unless a plugin forces otherwise. The work is identical and it buys two more years before you do this again.

Step two is the one people skip and regret. Changing PHP and updating twenty plugins in one sitting means that when something breaks you have twenty-one suspects.

What usually breaks

The last row is worth checking explicitly after the upgrade, because nothing on the site tells you. Run wp cron event list and confirm events are actually firing rather than accumulating. A stalled cron is also how a database fills with expired transients, which we cover in wp_options autoload bloat.

If you genuinely cannot upgrade

Sometimes a critical plugin has no supported replacement, or a custom integration needs real development. The answer is still not to sit on a dead runtime indefinitely, but you can manage the gap honestly.

• Put a date on it. An upgrade with no date is a decision to never upgrade.
• Reduce exposure meanwhile: a web application firewall, no file editing in the admin, tight file permissions, two-factor on every administrator.
• Know which component is blocking you and whether the fix is replacing it or paying someone a day to port it. Usually it is one plugin, and usually it is cheaper than people assume.
• Ask your host what they will do. Many force-upgrade unsupported versions eventually, and finding out by having it done to you on a Tuesday is worse than planning it.
• Write down the risk you are accepting, so it is a decision on record rather than an oversight.

One option worth naming because people reach for it: commercial backported security patches for dead PHP versions do exist. They are a bridge for a genuinely immovable system, not a reason to stop planning.

What to do today

1. Check your PHP version in Site Health. Thirty seconds
2. If it is below 8.3, put a date in the calendar before 31 December
3. List your active plugins and flag anything not updated in over a year
4. Ask your host whether staging is available, and whether web and CLI run the same version

Most sites on a current plugin set upgrade uneventfully, and the whole thing is an hour's work plus testing. The sites that have trouble are the ones that find out on 2 January.

If you would rather not discover your incompatibilities on a live site, we test and upgrade PHP on WordPress sites, including replacing the abandoned plugin that is usually the one thing blocking it. Send us your URL and your PHP version and we will tell you what will break before you commit to anything. Keeping this from recurring is what maintenance and support is for.