PHP 8.2 support ends 31 Dec 2026:check and switch your PHP version

If your site runs on PHP 8.2, it stops getting security fixes on 31 December 2026, so plan a move to PHP 8.3 or 8.4 now. The switch itself is one drop-down in your hosting panel and can usually be reversed if the previous version remains available, but you should back up and check your plugins first. PHP 8.1 already reached end of life on 31 December 2025, and php.net now lists it as unsupported.

Here is the strange part: many site owners have never looked at their PHP version. It sits in a menu nobody opens, and the site keeps working until a security hole appears that will never be fixed.

By the end of this guide you will know which PHP version your site uses, how to switch it safely in cPanel, Plesk or DirectAdmin, how to make your cron jobs follow, and how to roll back if something breaks.

What a PHP version actually is, and why the date matters

PHP is the programming language that WordPress and most shared-hosting sites are written in. Your host keeps several PHP versions on the server, and your hosting panel decides which one runs your site.

Think of it like a car engine. You can swap in a newer engine and the car usually drives better, but an old part that only fit the old engine may need replacing.

Each PHP branch goes through three stages, which php.net defines on its supported versions page:

• Active support: bugs and security issues are fixed, and regular point releases come out.
• Security fixes only: only critical security issues are fixed, and releases come out only when needed.
• End of life: no more support at all. php.net says users "should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities".

At the time of writing (3 October 2026), the php.net table says:

• PHP 8.2: active support ended 31 December 2024. Security support ends 31 December 2026.
• PHP 8.3: active support ended 31 December 2025. Security support until 31 December 2027.
• PHP 8.4: active support until 31 December 2026. Security support until 31 December 2028.
• PHP 8.5: released 20 November 2025. Active support until 31 December 2027, security support until 31 December 2029.
• PHP 8.1 and older: end of life. PHP 8.1 ended on 31 December 2025, and its last release was 8.1.34. PHP 8.0 ended on 26 November 2023.

These are upstream PHP support dates. Some hosts offer separate extended security support; confirm its coverage with your provider.

What WordPress recommends

The official WordPress requirements page recommends "PHP version 8.3 or greater", plus MariaDB 10.11 or MySQL 8.0 or greater, and HTTPS support. It adds that WordPress still works with PHP 7.4, but warns that those old versions "have reached their official End Of Life and may expose your site to security vulnerabilities."

The WordPress core compatibility chart lists WordPress 7.1 as compatible with PHP 7.4 through 8.5. So WordPress itself is rarely the problem. Your plugins and theme are the part to check.

Why this matters: a version that still works is different from a version that is still patched. A site on PHP 8.1 loads fine today, but any new PHP security flaw found from now on will not get a fix for it.

Which version should you pick?

For most WordPress sites in late 2026, PHP 8.4 is the sensible target if your plugins support it, because it is still in active support and gets security fixes until the end of 2028. PHP 8.3 is the safe minimum that WordPress recommends, and a good stepping stone if one plugin is not ready for 8.4 yet.

Quick tip: go one step at a time. If you are on 8.1, move to 8.3 first, test, then try 8.4. When something breaks, you will know which jump caused it.

Before you start

Give yourself about 30 to 60 minutes and pick a quiet time of day for your site. Here is what you need:

• A login to your hosting panel (cPanel, Plesk or DirectAdmin) or a message thread with your host's support.
• An admin login to WordPress, if your site is WordPress.
• A fresh backup of your files and your database, stored somewhere outside the server.
• A list of your plugins and your theme, with their versions.
• Optional: SSH access (a secure command-line login to the server) if you want to use WP-CLI, the official WordPress command-line tool.
• Optional: a staging copy of the site (a private test copy) if your host offers one.

Risk level: low to medium. The switch can take effect quickly and can usually be reversed if the previous version remains available, but an old plugin can crash the moment the new version loads, which is why backup and plugin checks come first.

Step-by-step: check, prepare and switch

Step 1: Find your current PHP version

In WordPress: go to Tools > Site Health > Info and open the Server section. It shows the PHP version and PHP settings such as the maximum upload size. A button there copies all site information to your clipboard for a support ticket.

In cPanel: open MultiPHP Manager (cPanel's documentation files it under the Software section). The list shows each domain and the PHP version it currently uses. If you see the Inherited label, PHP settings in the directory hierarchy can determine the version; otherwise, it falls back to the server default, which only the server administrator can set.

In Plesk: go to Websites & Domains, find your domain, and click PHP. The current version is shown in the drop-down.

In DirectAdmin: the version selector is on the domain's Domain Setup page.

With a temporary phpinfo file: if you cannot find it anywhere else, create a file in your site's main folder (usually public_html) with a random name such as check-7f3k9.php. This code prints the full PHP configuration, including the version and the loaded extensions:

<?php
phpinfo();

Open https://example.com/check-7f3k9.php in your browser. The version appears at the top of the page.

Heads up: delete this file as soon as you have read it. php.net describes phpinfo() output as including server information, paths, configuration values and environment data, which is a gift to anyone scanning your site. If you have SSH, this command removes it:

rm ~/public_html/check-7f3k9.php

Step 2: Know the difference between web PHP and command-line PHP

The PHP that serves your web pages and the PHP you get by typing php over SSH can be different versions with different settings.

This command shows the version of the command-line PHP:

php -v

If you use WP-CLI, this command shows which PHP binary and which PHP version WP-CLI itself is running on:

wp cli info

Why this matters: php.net documents that the command-line version (called the CLI SAPI) uses different defaults on purpose. For example, max_execution_time is 0 (no time limit) on the command line. So a script that works from SSH can still time out on the web, and the reverse.

Step 3: Back up before you touch anything

In cPanel, the Backup tool lets you download a Home Directory backup (your files) and each database by clicking its name under Databases. cPanel's docs note a full backup cannot be restored automatically from inside cPanel, only from WHM, so these partial backups are easier to restore yourself.

If you have WP-CLI, this command exports your WordPress database to a .sql file, adding drop-table statements so the file restores cleanly over an existing database:

wp db export /absolute/private/path/site-before-php.sql --add-drop-table

Before running the command, replace the example path with an existing writable directory outside every website's public document root. You should see a line that starts with Success: Exported to followed by the file name. Download the backup securely, verify your local copy, and remove the server copy when no longer needed. Never leave SQL backups in public_html or another publicly accessible folder.

For a deeper walk-through of backups and restores, see keeping a website resilient with backups and restores. If you ever need to move the whole site, this migration guide covers it.

Step 4: Update plugins and themes, then check them

Most PHP upgrade breakage comes from old plugins and themes, so update everything first. If you need a careful routine for updates, follow the same order as in our WordPress 7.1.2 update checklist.

With WP-CLI, this command lists plugins that still have an update waiting, with the current and available versions:

wp plugin list --update=available --fields=name,version,update_version

An empty list means WP-CLI found no available plugin updates; it does not check themes or prove PHP compatibility. Then check the page or changelog of each plugin you depend on (shop, forms, page builder, cache) for supported PHP versions. Plugins with no updates in years are the likely troublemakers.

A made-up example: "Lena" switches her bakery site from PHP 8.1 to 8.4. The home page looks perfect, so she goes to bed. Next morning, customers say the order form is blank, because an abandoned booking plugin broke. Ten minutes on plugin pages beforehand would have caught it.

Quick tip: if your host offers a staging copy, switch its PHP version first and test there. If not, switch the live site during a quiet hour and keep the panel open in another tab.

Switch the PHP version in cPanel (MultiPHP Manager)

Step 5: Change the version

These steps come from cPanel's official MultiPHP Manager documentation for cPanel users.

1. Log in to cPanel and open MultiPHP Manager in the Software section.
2. Tick the checkbox next to the domain you want to change.
3. Choose the new version from the PHP Version menu. If your host recommends some versions, you will see a Recommended label next to them.
4. Click Apply.

The domain's row should now show the new version. If you also use PHP-FPM (a faster way of running PHP that keeps worker processes ready), cPanel updates the FPM version to match.

A few things the cPanel docs point out:

• If the version you want is not in the menu, it is either not installed on the server or not available for your account. Ask your host to add it.
• If your host has limited your domain's PHP version, you cannot use this screen to set it back to the original version. Ask your host before you experiment.
• The inherit option follows PHP settings in the directory hierarchy, falling back to the server default. You cannot use PHP-FPM with inherit, so pick an actual version number.

Step 6: Re-check your limits in MultiPHP INI Editor

Each PHP version has its own settings file, so limits like memory_limit or upload_max_filesize can look different after a switch. Open MultiPHP INI Editor (also in the Software section).

• Basic Mode: choose Home Directory to apply settings to every site in your account, or pick one domain. Change the values and click Apply.
• Editor Mode: edit the php.ini text directly, then click Save. cPanel warns that mistakes here can stop PHP scripts from working, so use it only if you know the directive names.

cPanel recommends keeping its default values where you can, and notes that the available directives depend on your PHP version. If a directive is missing, that version does not support it.

Switch the PHP version in Plesk

From Plesk's official PHP settings documentation:

1. Go to Websites & Domains, find your domain, and click PHP.
2. Make sure PHP support is ticked.
3. Choose the new PHP version from the drop-down.
4. Choose the handler type from the drop-down (the handler is the way the web server runs PHP).
5. Click OK.

Plesk warns that "Different PHP versions are not 100% compatible." The same page lets you set common php.ini values, though your subscription may limit which ones.

Switch the PHP version in DirectAdmin

DirectAdmin's documentation says users choose between the installed PHP versions on their Domain Setup page. For a subdomain, the version is set under Sub-Domains Setup > Document Root Override, in the PHP Version Selector section.

No selector? Ask your host. If you run your own server, the admin side is covered in our DirectAdmin VPS install guide, and DirectAdmin's docs show the selector setting is checked with this command:

da config-get php_version_selector

DirectAdmin says the selector should be on by default, and turns it on with da config-set php_version_selector 1, so a result of 1 means enabled.

Make your cron jobs follow the new version

A cron job is a task the server runs on a schedule, such as sending reminder emails. A cron job may run a fixed PHP binary, use cPanel's version-aware wrapper, or request a web URL. A fixed binary will not follow a panel change, so inspect each command and verify the runtime it actually uses.

On cPanel servers, the official EasyApache docs say each installed PHP version has a command-line shortcut at /usr/local/bin/ea-php##, where ## is the two-digit version. So PHP 8.4 is /usr/local/bin/ea-php84.

This cron command runs a script with PHP 8.4 explicitly, using the absolute path to the script as cPanel's Cron Jobs documentation asks:

/usr/local/bin/ea-php84 /home/user/public_html/cron.php

Replace user and cron.php with your own values. In cPanel, edit the job in Cron Jobs, find it in the Current Cron Jobs list, click Edit, change the command, then click Edit Line.

On other panels the path differs, so ask your host rather than guessing.

How to check it worked

1. Site Health: reload Tools > Site Health > Info > Server in WordPress. The PHP version should show the new number.
2. The panel: the domain's row in MultiPHP Manager, or the PHP page in Plesk, should show the new version.
3. A fresh phpinfo file (optional): repeat Step 1 with a new random file name, confirm the version at the top, then delete the file straight away.
4. Click through what earns you money: home page, a blog post, the contact form (send yourself a test), search, login, the shop basket and checkout if you have one.
5. The admin area: log in to wp-admin, open the plugins page, and save a draft post.
6. The command line, for cron: check the selected PHP binary's version first. Test the task on staging or observe its next scheduled run; run it manually only when you know that repeating it will not duplicate emails, payments or other actions.

This command prints the version of the cPanel PHP 8.4 command-line binary, so you can confirm your cron will use it:

/usr/local/bin/ea-php84 -v

The first line should start with PHP 8.4.

Troubleshooting

"There has been a critical error on this website"

Symptom: the site shows "There has been a critical error on this website. Please check your site admin email inbox for instructions." or a completely blank white page.

Likely cause: a plugin or theme uses code the new PHP version no longer accepts. The WordPress docs list an incompatible PHP version among the common causes.

Fix: switch back to your old PHP version first, so visitors see a working site. Then check the site admin email inbox, as the message itself suggests, for details of what failed. Update or replace that plugin, and try the switch again.

You need to see the real error

Symptom: a blank page with no clue. Fix: on a private staging copy, turn on logging in wp-config.php so errors go to a file. Edit existing definitions of these constants and add only missing ones, above the line that says "That's all, stop editing!". Before enabling logging, ensure wp-content/debug.log cannot be downloaded publicly; ask your host if unsure:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Reload the affected staging page, then read wp-content/debug.log. When finished, set WP_DEBUG back to false and remove the diagnostic log. For a live-site failure, use the host's private PHP error log or ask support.

Deprecated warnings fill the log

Symptom: lots of lines containing "Deprecated" in the log, while the site still works. Likely cause: the plugin uses features that the new PHP version has marked for future removal. Fix: these are warnings, not failures. Update the plugin, or tell its developer. PHP's official migration guides for 8.3, 8.4 and 8.5 (linked from the supported versions page) list what changed.

A feature breaks because an extension is missing

Symptom: an error that mentions a missing function or class, for example image resizing or PDF features failing. Likely cause: each PHP version has its own set of installed extensions (add-on modules), and the new one may not have the extension your old version had. Fix: compare the extension lists in Site Health or phpinfo between the old and new versions. On cPanel, a server admin adds extensions in WHM > Home > Software > EasyApache 4, so on shared hosting you ask your host to install it.

"script not found or unable to stat" after a move

Symptom: the Apache error log shows script not found or unable to stat: /usr/local/cpanel/cgi-sys/ea-phpXX. Likely cause: an old handler line in .htaccess points to a PHP version the server no longer matches. cPanel writes a handler into the document root's .htaccess when you set a version, and it can go stale after an account transfer. Fix: cPanel's support article says to open .htaccess in File Manager, look for an AddHandler line such as the one below, and remove it if it does not match the version in MultiPHP Manager:

AddHandler application/x-httpd-ea-php73 .php .php7 .phtml

Then, in MultiPHP Manager, switch to another version and back again so cPanel rewrites the line. Back up .htaccess first. MultiPHP Manager only edits the document root's .htaccess, so if a subfolder still runs the old version, fix the AddHandler line in that subfolder's .htaccess by hand.

Your limits changed

Symptom: uploads fail or you see memory errors in the log that were not there before. Likely cause: the new version has its own php.ini with different values. Fix: set memory_limit, upload_max_filesize and post_max_size again in MultiPHP INI Editor or the Plesk PHP page.

How to roll back

Rolling back is the same move in reverse:

1. Open the same screen you used, ideally with the old version number written down before you switched (MultiPHP Manager, the Plesk PHP page, or DirectAdmin's Domain Setup).
2. Choose the previous version and apply it.
3. Put your cron commands back to the old path if you changed them.
4. Reload the site and confirm it works.

Switching PHP back does not undo plugin or theme updates, configuration edits, or data changes. Restore a backup only when necessary, taking care not to overwrite newer orders, submissions or other content. Remember that rolling back to 8.2 or older is a short-term fix only, because after 31 December 2026 those versions get no security fixes at all.

When to ask your host or a developer

Ask your host when the version you need is missing, the menu is locked, or an extension is missing. Ask a developer when a plugin you depend on has no update for PHP 8.3 or newer. If you run your own cPanel server, new versions are installed in EasyApache 4, and cPanel notes its profiles only ship PHP versions that php.net still supports.

The one message worth forwarding

If someone else looks after your site, send them this:

"Hi, PHP 8.2 stops receiving security fixes on 31 December 2026 (php.net supported versions page), and WordPress recommends PHP 8.3 or newer. Could you please check which PHP version our site and our cron jobs use, take a backup, update plugins and the theme, and switch us to PHP 8.4 (or 8.3 if a plugin is not ready)? Please test the contact form and checkout afterwards, and keep note of the old version so we can roll back if needed. Thank you!"

The takeaway: check your PHP version today, and move to 8.3 or 8.4 before 31 December 2026, with a backup in hand and an easy way back.