Hexloom PHP Compatibility Checker by Hexloom Labs

PHP 8.2 end of life: what to do before 31 December 2026

By Hexloom Labs. Updated .

PHP 8.2 stops receiving security fixes on 31 December 2026. A WordPress site on 8.2 will not stop working that day, but it will be running a PHP version that nobody maintains any more. This guide is for site owners and agencies who need a plan: what the date means, which version to move to, and a safe order of work.

What the date means

The PHP project supports each release for four years. In its own words:

“Each release branch of PHP is fully supported for two years from its initial stable release. […] After this two year period of active support, each branch is then supported for two additional years for critical security issues only. […] Once the four years of support are completed, the branch reaches its end of life and is no longer supported.”

PHP project, Supported Versions, as of 1 November 2026

For PHP 8.2, active support ended on 31 December 2024 and security support ends on 31 December 2026. After that date the PHP project publishes no more fixes for 8.2, so a security problem found later will not be fixed in 8.2 by PHP itself.

Supported PHP versions
VersionReleasedActive support untilSecurity support until
PHP 8.28 December 202231 December 202431 December 2026
PHP 8.323 November 202331 December 202531 December 2027
PHP 8.421 November 202431 December 202631 December 2028
PHP 8.520 November 202531 December 202731 December 2029

Source: php.net/supported-versions.php, as of 1 November 2026. The first row, PHP 8.2, is the one this guide is about.

What the date does not mean: PHP 8.2 does not switch itself off, and your site does not break on 1 January. Your host decides how long a version stays available on its servers, which is why the questions further down matter.

How many WordPress sites are affected

WordPress.org publishes the share of sites by PHP version. As of 1 November 2026, about 56 percent of WordPress sites were on PHP 8.2 or older and about 44 percent on 8.3 or newer. PHP 8.2 alone was 22.9 percent.

Source: api.wordpress.org/stats/php, as of 1 November 2026. Shares are rounded to one decimal place, so the rows may not add up to exactly 100.

Every version below 8.2 has already dropped out of the php.net list above, and about 33 percent of sites run one of them. If yours is one of those sites, the steps below apply to you too, with more changes to cross.

Find your PHP version

In the WordPress admin, go to Tools > Site Health, open the Info tab and expand Server. The line “PHP version” shows what the site runs today. Check every site you manage: the version can differ from site to site on one host, and between a staging copy and the live site.

Which version to move to

WordPress itself recommends a recent one:

“To run WordPress, it’s recommended your host supports: PHP version 8.3 or greater.”

WordPress.org, Requirements, as of 1 November 2026

Under the PHP project’s schedule, security support lasts until 31 December 2027 for 8.3, 31 December 2028 for 8.4 and 31 December 2029 for 8.5. A newer version gives you a longer window before the next forced move, but it also crosses more changes, so older plugins and themes are more likely to log problems on 8.5 than on 8.3. Version 8.3 is also the one most WordPress sites run today, at 27.6 percent.

A practical rule: test on the newest version you would be happy to run. If a plugin fails there, try one version lower before you consider staying on 8.2.

What to ask your host

Send these to your host’s support, or find the answers in its documentation:

  • Which PHP versions can I choose, and can I set the version for each site separately?
  • Which version do you recommend for WordPress, and how long will PHP 8.2 stay available on my plan?
  • What happens to sites still on 8.2 after 31 December 2026: will you upgrade them, patch them yourselves or leave them as they are?
  • Is there a staging environment, and can it run a different PHP version from the live site?
  • Where do I read the PHP error log, and can I switch back to the old version in the control panel if something fails?

A safe order of work

Do the work on a copy first, in this order.

  1. Back up. Take a full backup of the files and the database, and check that you can restore it.
  2. Make a staging copy on the same host, so it runs the same server software as the live site.
  3. Update on staging first, while it still runs the old PHP version: WordPress, then plugins, then themes. Authors often fix PHP problems in new releases, and updating first keeps an update problem from being mistaken for a PHP problem.
  4. Switch staging to the new PHP version and turn on logging. Add these lines to wp-config.php, above the line that says “That’s all, stop editing”:
    wp-config.php
    define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
  5. Click through the site: the home page, a post, search, login, forms, checkout if you sell, the admin screens you use every week, and anything that runs on a schedule, such as emails, imports and backups. Then read wp-content/debug.log. Deal with fatal errors first, then warnings, then deprecations. Report a problem to the plugin’s support forum with the line from the log.
  6. Switch the live site in a quiet hour, after a fresh backup, with the old PHP version still one click away in your host’s panel. Watch the log for a few days, then turn logging off and delete debug.log.

What typically breaks

Many of the changes in PHP 8.3, 8.4 and 8.5 are deprecations: the code still runs and PHP logs a notice. Trouble tends to look like one of these.

  • Notices on screen. If your host displays errors instead of only logging them, a notice can land inside a page, a JSON response or a redirect and break it. Keep display off and logging on, as in step 4.
  • Removed extensions. PHP 8.4 no longer bundles IMAP, OCI8, PDO_OCI and PSpell; they moved to PECL. A plugin that needs one stops working unless the host installs it (PHP manual).
  • Old, unmaintained code. A plugin or theme that has not been updated for years is the most likely to hit a fatal error, because nobody has run it on a recent PHP. WordPress then shows its critical-error screen instead of the page.

The plugin compatibility guide lists ten deprecations to look for, with the notice PHP prints for each.

Checking plugins and themes in advance

No label tells you whether a plugin runs on a given PHP version, and nobody can promise it from the outside. There are three ways to find out, each with limits:

  • A staging test with the debug log, as above. It runs the real code with your settings, but only the code you trigger while clicking.
  • The plugin’s changelog, support forum and “Requires PHP” field. These are statements by the author about earlier releases, not a test on your site.
  • A static scan, which reads the code without running it and lists constructs that newer PHP versions removed or deprecated. It covers every file, but it cannot tell whether a flagged line ever runs. The box below describes one.

The plugin compatibility guide compares the three in more detail.

Sources

General information, not a guarantee for any particular site. Test on a copy before you change your live site. Dates and figures change; this page was last checked on 1 November 2026.