WordPress PHP version: how to check yours and move off PHP 8.2 before 31 December

Which WordPress PHP version is your site running?

Your WordPress PHP version is one line in the dashboard. Open Tools, then Site Health, then the Info tab, and expand Server. The line reads “PHP version”, followed by the exact number.

If you cannot log in, your hosting panel or your host can tell you the same number.

Write the number down. If it starts with 8.2, the rest of this post is your plan for the next ten weeks. Keeping PHP current is part of what our WordPress maintenance care plan covers each month.

Why does PHP 8.2 matter now?

PHP 8.2 gets its last security fixes on 31 December 2026. PHP.net’s supported versions page lists that date, and after it no new security fix comes out for 8.2.

Active support for 8.2 ended on 31 December 2024. Since then it has been on security fixes only. Every version older than 8.2 is already past the end of its security support.

The newer versions run longer:

WordPress.org’s requirements page recommends PHP 8.3 or greater. The WordPress core handbook lists 8.3 and 8.4 as supported in WordPress 6.7 through 7.1.

What does Site Health say about PHP 8.2?

Site Health asks WordPress.org about your PHP version through an API called serve-happy. We asked it ourselves on 16 Oct 2026.

For 8.2 it answered is_supported false and is_secure true, with 8.3 as the recommended version. For 8.3 and 8.4 it answered is_supported true.

In the Site Health source, that pair of answers leads to a “recommended” item headed “Your site is running on an older version of PHP”, followed by the version and “which should be updated”.

If your Site Health screen also lists other items, our post on which Site Health critical issues to fix first sorts them by risk.

Who decides which PHP version your site uses?

Your host does. PHP runs on the server, not inside WordPress, so you cannot change it from a plugin or a setting in wp-admin.

Most hosting panels let you pick the version per site from a list. Ask your host which versions your plan offers. If 8.3 or 8.4 is not on the list, that is a reason to ask about a plan change or a move.

How do you move off PHP 8.2 without breaking the site?

This is the order we follow:

1. Note the PHP version and the WordPress version today, from Site Health.
2. Take a backup you have restored at least once.
3. Make a staging copy of the site. Some hosts have a staging tool in the panel.
4. Switch only the copy to PHP 8.3 or 8.4.
5. On the copy, set WP_DEBUG and WP_DEBUG_LOG to true in wp-config.php. WordPress then writes errors and warnings to wp-content/debug.log.
6. Click through the pages that matter: the home page, the contact form, and the cart and checkout if you sell.
7. Read the log. A plugin that complains on the copy is the one to update or replace first.
8. Switch the live site, then check the same pages again.

WordPress’s own debugging guide says WP_DEBUG is meant for local and staging installs, not live sites. Turn it off on the copy when you are done, because Site Health itself flags a debug.log in wp-content as “a potentially public file”.

This is the fix we do as a one-off job: we switch a copy, read the log, update or replace the plugins it names, and only then change the live site.

What does a PHP problem look like in the log?

Most of the time it is a line about old code, not a crash. We wrote a short test file in a style many older plugins use. On 16 Oct 2026 we ran it on PHP 8.4.13:

function lab_greet( string $name = null ) { return "Hi " . $name; }

PHP 8.4 printed: “Deprecated: lab_greet(): Implicitly marking parameter $name as nullable is deprecated, the explicit nullable type must be used instead”. The function still ran. PHP 8.4’s migration guide lists this exact pattern as deprecated, and the deprecation is new in 8.4, so PHP 8.2 runs the same line without the notice.

A deprecation notice is a warning for the future, not an error today. Lines that say “Fatal error” are different: they stop the page. Fatal errors that name memory have their own fix in our post on the WordPress memory exhausted critical error.

What did we not test?

• A full WordPress site switched from 8.2 to 8.3 or 8.4. Our test was one file on the PHP command line.
• Real plugins. Which ones warn depends on their code and their version.
• Any host’s panel. The menu names differ from host to host.

Is your site still on PHP 8.2?

Check the version line in Site Health today. If it says 8.2 and you would rather not run the staging test yourself, tell us your PHP and WordPress versions and we will plan the move with you before 31 December.