PHP 8.2 Security Support Ends 31 Dec: Move Your Site Now

PHP 8.2 gets its last security fixes on 31 December 2026, so any site still on 8.2 should move to PHP 8.3 or newer before then. The switch itself takes a few clicks in cPanel, Plesk or DirectAdmin. The real work is the backup and the test run before it, and that is what this guide walks you through.

Here is the odd part. At the time of writing (1 November 2026), the WordPress hosting handbook lists PHP 8.2 to 8.5 as supported for WordPress 7.1, and cPanel's default EasyApache profile still includes PHP 8.2. Nothing on your dashboard is shouting. But after 31 December, any newly found hole in 8.2 stays open on your server.

By the end, you will be able to back up, test on PHP 8.3, switch in your control panel, confirm it worked, and roll back in a minute if something breaks.

What "end of security support" actually means

Every PHP branch (a version family like 8.2 or 8.3) lives on a fixed schedule. php.net says each branch is fully supported for two years from its first stable release, with bug fixes and security fixes in regular point releases. After that it gets two more years of fixes "for critical security issues only", released only when needed.

When those four years end, the branch is unsupported. php.net's end of life page says that people on unsupported releases are "strongly urged to upgrade to a current version, as using older versions may expose you to security vulnerabilities and bugs that have been fixed in more recent versions of PHP."

Think of it like a car model the maker no longer makes parts for. The car still drives on 1 January. But the next time a part fails, nobody ships the fix, and you are on your own.

At the time of writing (1 November 2026), the php.net supported versions page lists these dates:

• PHP 8.2: released 8 December 2022, active support ended 31 December 2024, security support until 31 December 2026.
• PHP 8.3: released 23 November 2023, active support ended 31 December 2025, security support until 31 December 2027.
• PHP 8.4: released 21 November 2024, 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 already went this way: it reached end of life on 31 December 2025, and its last release was 8.1.34.

Which version should you pick?

My advice: treat PHP 8.3 as the floor, not the goal. The WordPress requirements page recommends "PHP version 8.3 or greater", along with MariaDB 10.11 or newer or MySQL 8.0 or newer, and HTTPS support.

• PHP 8.3 is the smallest jump from 8.2, so it is the safest first move for an older site. It is covered until 31 December 2027, which gives you one more year.
• PHP 8.4 buys you security fixes until 31 December 2028. Good if your plugins and theme are well maintained.
• PHP 8.5 is the newest branch. Do not pick it just because it is at the top of the list. Pick it only after your site passes a test on it.

Why this matters: php.net's migration guides for 8.3 and 8.4 both warn of "a few incompatibilities that should be tested for before switching PHP versions in production environments." Going 8.2 to 8.3 means reading one list of changes. Going 8.2 to 8.5 means three.

For the critical PHP remote code execution bug, see the separate guide: patching CVE-2026-109618 on your hosting.

Before you start

Give yourself an hour for a normal WordPress site, including testing. The switch is low risk because you can undo it, but a site with old plugins can break the moment the new version loads.

• Control panel login: cPanel, Plesk or DirectAdmin access for the account that hosts the site.
• WordPress admin login: an Administrator account, so you can open Site Health.
• Optional SSH access: for the WP-CLI steps. WP-CLI is the command line tool for WordPress. Skip those steps if you do not have it.
• A full backup: files plus database, saved somewhere you can reach even if the site is down. Step 1 covers this.
• A staging copy, if you can: a private clone of the site where you test first. Your host may offer a staging tool for this.

Heads up: on shared hosting you can only choose versions your host has installed. cPanel's documentation says that if a version is missing from the menu, it may not be installed or available for your account, and only your administrator can install it. If 8.3 or 8.4 is not offered, ask your host before you do anything else.

Step-by-step: move from PHP 8.2 to 8.3 safely

Step 1: Take a full backup in cPanel

A full backup gives you every file and the database in one archive, so whatever happens next, you can get back to exactly where you were.

1. In cPanel, open Backup Wizard (cPanel documents it in the Files section).
2. Click Back Up.
3. Click Full Backup.
4. In the Backup Destination menu, choose Home Directory.
5. Enter your email address so cPanel tells you when it finishes.
6. Click Generate Backup, then Go Back and click the file name to download it to your computer.

You should see a new archive in your home directory and, after a while, a completion email.

Heads up: cPanel says "You cannot automatically restore a full backup file in cPanel." That needs your host. So also take two partial backups from the same wizard: Back Up > Home Directory (a .tar.gz file) and Back Up > MySQL Databases (a .sql file). Partial backups can be restored yourself under Restore.

Quick tip: cPanel warns that a backup for an account near or over its disk quota may fail. Delete old backups or ask for more space first.

Step 2: Export the database with WP-CLI (optional)

With SSH, a second database copy takes seconds. This command writes the database to a .sql file in your home directory, outside the public web folder.

cd ~/public_html
wp db export ~/backup-before-php83.sql

You should see a line starting with Success: and the file name.

Step 3: Find out which PHP version the site really runs

In WordPress, go to Tools > Site Health. On the Status tab, an outdated PHP version shows as a critical issue labelled "Type: Security". On the Info tab, copy all site information to the clipboard and paste it into a text file, as a snapshot of the setup before the change.

For a direct answer from PHP itself, create a tiny test file. This file prints the PHP version that the web server uses for this exact folder.

<?php
echo 'Current PHP version: ' . phpversion();

Save it as php-version-check.php inside public_html with File Manager or over SFTP. Then load it from your terminal with this command.

curl -s https://example.com/php-version-check.php

You should see something like Current PHP version: 8.2.x. Keep the file for now, you will use it again in the checks section, then delete it.

If you use WP-CLI, this command prints the PHP binary and version that WP-CLI itself runs on.

wp cli info

Look for the PHP binary: and PHP version: lines. Heads up: this is the command line PHP, which can differ from the PHP serving your website. The test file shows what visitors get.

Step 4: Update everything while you are still on 8.2

Old plugins are the usual suspects when a PHP upgrade breaks a site. Compatibility fixes arrive in new plugin releases, so update first, on the version you know works.

This command lists each plugin, whether it is active, and whether an update is waiting.

wp plugin list --fields=name,status,update,version

This command previews which plugins would update, without changing anything.

wp plugin update --all --dry-run

When the list looks right, run the real update.

wp plugin update --all

You should see a table with each plugin's old and new version and a status. Without SSH, update your plugins from the WordPress admin instead. For core updates by command line, see our walkthrough on updating WordPress 7.1.4 with WP-CLI.

Next, look for abandoned plugins. This command asks WordPress.org whether each plugin is still listed there and when it was last updated.

wp plugin list --fields=name,wporg_status,wporg_last_updated

A plugin that has not seen an update in years is your most likely troublemaker. Note its name. You will watch for it in the logs.

Step 5: Scan your code for the common PHP 8.3 changes

php.net's PHP 8.3 migration guide has separate pages for backward incompatible changes and deprecated features. "Deprecated" means it still works, but PHP warns that it will go away in a later version.

A few changes that bite real sites, all from the official pages:

• Calling get_class() or get_parent_class() with no arguments is now deprecated.
• assert_options() is deprecated, along with the ASSERT_ACTIVE, ASSERT_BAIL, ASSERT_CALLBACK, ASSERT_EXCEPTION and ASSERT_WARNING constants.
• range() now throws a TypeError for objects, resources or arrays as boundaries, and a ValueError for a step of 0 or a negative step on an increasing range.
• number_format() now handles negative decimals values by rounding, where earlier versions ignored them.

This rough search lists lines in your plugins and themes that use some of the deprecated calls. It is a quick hint, not a full audit.

cd ~/public_html
grep -rnE "assert_options|get_class\(\)|get_parent_class\(\)|MT_RAND_PHP" wp-content/plugins wp-content/themes

No output is a good sign. A match tells you which plugin to watch. For custom code, send your developer the official PHP 8.3 backward incompatible changes page.

Step 6: Turn on logging so you can see what breaks

You want errors written to a log file, not printed on the page where visitors see them. The WordPress debugging documentation shows this setup in wp-config.php.

Open wp-config.php in File Manager, and add these lines before the line /* That's all, stop editing! Happy blogging. */.

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

With WP_DEBUG_LOG set to true, WordPress saves the log as debug.log in the content folder, usually wp-content/debug.log. Setting WP_DEBUG_DISPLAY to false keeps the messages off the page.

Heads up: the WordPress documentation says it is not recommended to use WP_DEBUG or the other debug tools on live sites. Use this on staging. If you must test on the live site, keep it on only for the test window and remove the lines afterwards (Step 9).

Step 7: Test on a staging copy first

Made-up example: a small bakery site with a booking plugin last updated four years ago. On the live site, a switch to 8.3 could break checkout on a busy morning. On staging, the same break costs nothing: you read the log, replace the plugin, and move on.

Create the staging copy with your host's staging tool, or clone the site by hand. If you have never done this, our guide to testing a WordPress beta on staging shows the full setup, and the same copy works for a PHP test.

On staging, do Step 8 below, then click through every page that matters: homepage, a post, the contact form, login, cart and checkout. Check wp-content/debug.log after each.

Step 8: Switch the PHP version in cPanel MultiPHP Manager

MultiPHP Manager is the cPanel screen that sets a PHP version per domain. Here is how cPanel's documentation describes the change.

1. In cPanel, open MultiPHP Manager.
2. Select the checkbox next to the domain you want to change.
3. Choose PHP 8.3 from the PHP Version menu. Versions marked "Recommended" are the ones your system administrator suggests.
4. Click Apply.

You should see the domain's version change in the list. Do this on staging first, then repeat it on the live site once staging is clean. If PHP-FPM is enabled for the domain, cPanel updates the FPM version to match. PHP-FPM is a way of running PHP that handles more requests by using pools of worker processes.

Why this matters: do not pick inherit here. cPanel says inherit makes the domain "always use the system default", which only the server administrator controls. It also says "You must select a PHP version other than inherit to enable PHP-FPM on a domain." Pick a specific version so you know what you are running.

Heads up: cPanel says that when you enable the PHP-FPM setting for a domain that shares a document root with other domains, the change applies to all domains that use that document root. Refresh the page to see the updated PHP-FPM setting for all related domains.

Step 9: Turn debugging back off

Once testing is done and the site is clean, remove the four lines you added in Step 6, or set WP_DEBUG back to false. Then delete wp-content/debug.log so old paths and messages do not sit in a public folder.

Rollback: back to 8.2 in under a minute

If the site breaks and you need it up right now, go back to MultiPHP Manager, select the domain's checkbox, choose PHP 8.2, and click Apply. The site should load as before. This buys you time to fix the problem. It does not buy you past 31 December.

Heads up: if your host has limited the PHP versions on your account, cPanel's documentation says you cannot use this interface to restore the domain's original version. In that case, ask your host, or restore from your Step 1 backup.

Doing the same in Plesk or DirectAdmin

Plesk Obsidian

1. Go to Websites & Domains > PHP settings.
2. Select the PHP version you want from the menu.
3. If the version is not listed, contact your hosting provider.

Depending on your subscription, Plesk may not let you change some settings at all.

DirectAdmin

DirectAdmin's documentation says users choose a version on the Domain Setup page. For subdomains it sits under Sub-Domains Setup > Document Root Override, in the PHP Version Selector section. The selector only appears if the server administrator has enabled it and built the PHP versions to offer, so if you do not see it, ask your host.

How to check it worked

Run these checks right after the switch, and again the next day.

• The test file: run curl -s https://example.com/php-version-check.php again. You should see Current PHP version: 8.3.x. Then delete php-version-check.php, because it tells strangers which version you run.
• Site Health: open Tools > Site Health in WordPress. The outdated PHP warning should be gone from the Status tab.
• Front end: load the homepage, a single post and your contact form in a private browser window. Submit the form to yourself.
• Logins and checkout: log out and back in. If you sell anything, place a test order with your payment provider's test mode.
• The error log: in cPanel, open Metrics > Errors. cPanel shows up to 300 of the most recent web server error log entries for your domains, newest first. You want no new entries after the switch time.
• The WordPress log: if debugging is still on, check the end of the log with this command.

tail -n 50 ~/public_html/wp-content/debug.log

You want nothing, or only lines you already understand. A line containing Deprecated is a warning for the future. A line containing Fatal error is something broken now.

Troubleshooting

The site shows a blank page or a critical error right after the switch

• Likely cause: a plugin or theme uses something PHP 8.3 changed or removed.
• Fix: roll back first (see Rollback above). Then on staging, read wp-content/debug.log. The file path in the Fatal error line names the plugin or theme folder. Update it, replace it, or ask its developer.

If you need to find the culprit on staging with SSH, this command turns off one plugin by its slug.

wp plugin deactivate plugin-slug

To turn off every plugin except a few you trust, this command keeps the ones you list active.

wp plugin deactivate --all --exclude=woocommerce,wordpress-seo

Turn them back on one at a time with wp plugin activate plugin-slug and reload the site each time. The one that breaks it is your answer.

PHP 8.3 is not in the PHP Version menu

• Likely cause: the version is not installed on the server, or not offered on your plan.
• Fix: ask your host. cPanel's documentation says only the administrator can install versions, through EasyApache 4 in WHM. EasyApache 4 supports PHP 7.4 and 8.1 to 8.5, so this is a host choice, not a cPanel limit.

"I cannot turn on PHP-FPM for my domain"

• Likely cause: the domain is set to inherit.
• Fix: choose a specific version such as PHP 8.3 in MultiPHP Manager. cPanel will not allow PHP-FPM while the version is inherit.

The backup failed

• Likely cause: the account is near or over its disk quota.
• Fix: free up space by removing old backup archives, or ask your host for a temporary quota increase, then run the Backup Wizard again.

The log is full of Deprecated lines

• Likely cause: code using features PHP 8.3 deprecated, such as get_class() with no arguments.
• Fix: the site still works. Note which plugin each line points to and check for updates before the next PHP upgrade.

The site got slow after a change in Plesk

• Likely cause: a changed PHP setting, not the version itself.
• Fix: Plesk's documentation says to return all PHP settings to their default values, then try the version change again.

When to ask your host or a developer

Ask your host when the version you need is missing, when you cannot see MultiPHP Manager (hosts can hide it in WHM's Feature Manager), or when you need a full restore. Ask a developer when the fatal error points at custom code or a plugin no longer on WordPress.org, and send them the log lines plus the official migration page.

Quick tip: once you are on 8.3, put a date in your calendar for autumn 2027. The same thing happens to 8.3 on 31 December 2027, and you will want to repeat this process on your own schedule again.

The one message worth forwarding

"Hi, PHP 8.2 stops receiving security fixes on 31 December 2026 (source: php.net/supported-versions.php). Our site still runs 8.2. Can we take a full backup, test the site on PHP 8.3 on a staging copy this month, and then switch the live site in the control panel? If anything breaks, we can switch back to 8.2 in a minute while we fix it. Can you confirm PHP 8.3 or 8.4 is available on our server?"

PHP 8.2 is not broken today, but from 1 January 2027 nobody fixes it, so back up, test on 8.3, and switch before the year ends.