PHP 8.2 end of life: what WordPress site owners should do

Q: How do I see which PHP version my site runs?

In your WordPress admin, go to Tools → Site Health, open the Info tab and then the Server section: it shows the PHP version. Your hosting control panel shows it too.

What “end of life” means

The PHP project supports each version (a “release branch”) in three phases, as described on php.net:

Active support, two years: “bugs and security issues that have been reported are fixed and are released in regular point releases.”
Security fixes only, two more years: the version is “supported for critical security issues only.”
End of life: the version “is no longer supported. Users of this release should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities.”

For PHP 8.2, the last phase ends on 31 December 2026. Nothing on your site switches off that day: the same code keeps running the same way. What changes is that security problems found in PHP 8.2 after that date are no longer fixed by the PHP project.

The dates at a glance

Active support Security fixes only Dates from php.net, checked 28 September 2026.

PHP version	Released	Active support until	Security fixes until
8.2	8 Dec 2022	31 Dec 2024	31 Dec 2026
8.3	23 Nov 2023	31 Dec 2025	31 Dec 2027
8.4	21 Nov 2024	31 Dec 2026	31 Dec 2028
8.5	20 Nov 2025	31 Dec 2027	31 Dec 2029

On the same day PHP 8.2 reaches its end of life, PHP 8.4 moves from active support to security fixes only. That needs no action: PHP 8.4 keeps getting security fixes until the end of 2028.

Is WordPress ready for PHP 8.3, 8.4 and 8.5?

WordPress itself is. The WordPress core team’s compatibility table lists WordPress 7.1, the current version, as compatible with PHP 7.4 to 8.5.

The same page adds that WordPress “is rarely used in isolation (without any theme or plugins)”. Whether your site is ready depends on your plugins and your theme, and that is what the rest of this guide is about.

Which version should you move to?

PHP 8.5 is supported the longest: security fixes until 31 December 2029.
PHP 8.4 gets security fixes until 31 December 2028.
PHP 8.3 is the smallest step from 8.2, but its security fixes end on 31 December 2027, so the same question comes back a year later.

Your host decides which versions you can choose. If your plugins and theme are ready for it, the newest version your host offers gives you the most time before the next move.

You don’t need to go through 8.3 and 8.4 one at a time. What matters is that you check everything that changes between PHP 8.2 and the version you choose. CompatNav, for example, compares the version your site runs today with the one you choose and reports only what changes between the two.

What changes when you leave PHP 8.2

Most changes between PHP 8.2 and 8.5 are deprecations: the code keeps working, and PHP writes a notice (“Deprecated: …”) saying that this will change in a future version. A few changes are incompatible: code that relies on them stops with an error. Three typical deprecations, one per version:

PHP 8.3: calling get_class() without arguments (php.net).
PHP 8.4: a typed parameter whose default is null without a ? in its type, called an implicitly nullable parameter (php.net).
PHP 8.5: the backtick operator (`…`) as a shortcut for shell_exec() (php.net).

All three keep working on the new version; they only add notices. The changes that can stop a page are listed in php.net’s backward-incompatible changes for PHP 8.3, PHP 8.4 and PHP 8.5; the PHP 8.5 ones are explained in WordPress and PHP 8.5: what breaks, what only shows notices.

One PHP 8.4 change isn’t about code at all: the IMAP, OCI8, PDO_OCI and PSpell extensions “have been moved to PECL and are no longer part of the PHP distribution” (php.net). A plugin that uses PHP’s IMAP functions to read email, for example, only works on PHP 8.4 and later if your host installs that extension separately. That is a server setting, not something a check of your code can see, so ask your host.

This is how a check reports the PHP 8.4 case in a plugin:

For developers

Each example below ran on the official PHP builds. The first output is the version you leave, the second the version you move to.

PHP 8.3: get_class() without arguments.

example.php

<?php
class Invoice {
    public function describe(): string {
        return 'Created by ' . get_class();
    }
}

echo (new Invoice())->describe(), "\n";

Output on PHP 8.2.34

Created by Invoice

Output on PHP 8.3.35

Deprecated: Calling get_class() without arguments is deprecated in /var/www/html/example.php on line 4
Created by Invoice

Inside a class, self::class gives the same name without a notice, on every PHP version. (If the code needs the class of the actual object, including subclasses, that is static::class.)

example.php

<?php
class Invoice {
    public function describe(): string {
        return 'Created by ' . self::class;
    }
}

echo (new Invoice())->describe(), "\n";

Output on PHP 8.3.35

Created by Invoice

PHP 8.4: implicitly nullable parameters. The notice appears as soon as the file is compiled, even if the function is never called.

wp-content/plugins/price-format/includes/format.php

<?php
function format_price(float $amount, string $currency = null): string {
    return number_format($amount, 2) . ' ' . ($currency ?? 'EUR');
}

echo format_price(19.9), "\n";

Output on PHP 8.3.35

19.90 EUR

Output on PHP 8.4.26

Deprecated: format_price(): Implicitly marking parameter $currency as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/wp-content/plugins/price-format/includes/format.php on line 2
19.90 EUR

Adding ? to the type says the same thing explicitly. ?string works since PHP 7.1, so the fix is safe for older sites too:

wp-content/plugins/price-format/includes/format.php

<?php
function format_price(float $amount, ?string $currency = null): string {
    return number_format($amount, 2) . ' ' . ($currency ?? 'EUR');
}

echo format_price(19.9), "\n";

Output on PHP 8.4.26

19.90 EUR

PHP 8.5: the backtick operator.

example.php

<?php
$greeting = `echo hello`;
echo trim($greeting), "\n";

Output on PHP 8.4.26

hello

Output on PHP 8.5.11

Deprecated: The backtick (`) operator is deprecated, use shell_exec() instead in /var/www/html/example.php on line 2
hello

example.php

<?php
$greeting = shell_exec('echo hello');
echo trim($greeting), "\n";

Output on PHP 8.5.11

hello

A safe plan in six steps

Find out which PHP version your site runs: in WordPress go to Tools → Site Health → Info → Server.
Ask your host when it plans to move sites off PHP 8.2, which versions you can choose, whether you can switch back, and whether it offers a staging copy of your site to test on.
Make a backup of your site: files and database.
Check your plugins and theme for the version you chose, on a staging copy if you have one.
Fix what the check finds: update the plugin or theme, ask its developer, or replace it. Not ready yet: what to do explains each option.
Switch, then watch: change the PHP version in your hosting panel, visit your important pages and forms, and look at your error log over the next few days.

If something breaks after the switch, go back to the previous PHP version first; “There has been a critical error” after a PHP update shows how to find the cause.

Key takeaways

PHP 8.2 receives security fixes until 31 December 2026 (php.net). Nothing switches off that day, but security problems found afterwards are no longer fixed by the PHP project.
WordPress 7.1 itself works with PHP 7.4 to 8.5. Whether your site does depends on your plugins and theme.
PHP 8.5 is supported the longest (until 31 December 2029); PHP 8.3 is the smallest step, but only until 31 December 2027.
Most changes after PHP 8.2 are deprecation notices: the code keeps working. A few changes can stop a page, so check before you switch.
Plan: find your current version, ask your host, back up, check plugins and theme, fix what the check finds, then switch and watch the site for a few days.

Frequently asked questions

Will my site stop working on 1 January 2027?

No. PHP doesn’t switch off: the same code keeps running the same way. What ends is the PHP project’s support: security problems found in PHP 8.2 after 31 December 2026 are no longer fixed by php.net. Your host may also decide to move sites off PHP 8.2 around that date.

Can I stay on PHP 8.2?

Only if your host keeps offering it. The PHP project itself stops publishing fixes for it, so ask your host whether it will keep PHP 8.2 available after 31 December 2026, on what terms, and until when.

Which PHP version should I choose?

The newest version your host offers that your plugins and theme are ready for. PHP 8.5 has security fixes until 31 December 2029, PHP 8.4 until 31 December 2028 and PHP 8.3 until 31 December 2027. See Which version should you move to?

How do I see which PHP version my site runs?

In your WordPress admin, go to Tools → Site Health, open the Info tab and then the Server section: it shows the PHP version. Your hosting control panel shows it too.

PHP 8.4’s active support also ends on 31 December 2026. Do I need to do anything about that?

No. On that day PHP 8.4 moves from active support to security fixes only, which continue until 31 December 2028.

Check your own site before you upgrade

CompatNav is a free WordPress plugin. It reads the code of your plugins and themes on your own server and tells you, in plain words, what will break and what will only show notices on the PHP version you choose. It never changes your code. It can’t see problems that only appear while code runs with real data, so a quick check of your site after the upgrade still matters.

Get CompatNav on wordpress.org How it works

Sources

About the code examples: each output is the real output of the code shown, run with the official PHP builds, without a php.ini, with all errors reported and displayed. Only the file path was replaced by a neutral server path.