PHP 8.2 End of Life (Dec 31, 2026): WordPress Upgrade Plan

PHP 8.2 reaches end of life on 31 December 2026. From 1 January 2027 the PHP project publishes no more fixes for the 8.2 branch, not even for critical security issues. Your WordPress site will keep running, but any PHP vulnerability found after that date gets no official fix for 8.2. The fix is a planned move to PHP 8.3, 8.4 or 8.5, tested on a staging copy first.

This guide gives you the official dates, helps you choose a target version and walks through an upgrade plan you can follow yourself or hand to your developer. Dates were checked against php.net and WordPress.org on 27 September 2026.

What happens on 31 December 2026

Current PHP branches get two years of active support (regular bug and security fixes), then two years of security support (critical security fixes only, released as needed). PHP 8.2 left active support on 31 December 2024 and has received security fixes only since then. On 31 December 2026 those stop too. The PHP supported versions page is direct about what that means: users of an end-of-life release “may be exposed to unpatched security vulnerabilities”.

Nothing switches off on 1 January 2027. What changes is the risk, and it grows every month:

• Security: new vulnerabilities in PHP 8.2 itself will not be fixed by the PHP project. Updating WordPress, plugins and themes does not cover the language they run on.
• Plugin updates: plugin developers raise their minimum PHP version over time. When a new release needs a newer PHP version than your server runs, the Plugins screen says the update does not work with your version of PHP and offers no update link, so you can miss plugin security fixes without noticing. WordPress also refuses to activate a plugin that requires a higher PHP version, as announced in the WordPress 5.2 release.
• Hosting: hosts handle upstream end of life differently. Some move sites to a newer version on their own schedule, some keep older versions available with their own or a vendor’s patches, and some leave the old version in place. Ask your host what will happen to your plan and when, because an untested automatic switch is a risk of its own.
• Business exposure: if your site takes payments, runs member logins or stores customer data, “our website runs on software that no longer gets security fixes” is a hard answer to give a customer, insurer or payment provider.

WordPress itself is not the deadline. The WordPress PHP compatibility matrix still lists PHP 8.2 as supported by WordPress 7.1, and the WordPress requirements page recommends PHP 8.3 or greater. The deadline is PHP’s own end of security support.

PHP supported versions (2026)

As of 27 September 2026, php.net lists four supported PHP branches: PHP 8.4 and 8.5 are in active support, and PHP 8.2 and 8.3 receive security fixes only. PHP 8.1 and every older branch are end of life. PHP 8.2 is the next branch to drop out.

Two details explain the dates. Under the release cycle update accepted in 2024, branches from PHP 8.1 onwards get two years of security fixes instead of one, and their support ends on 31 December rather than on the release anniversary. That is why PHP 8.2, first released on 8 December 2022, reaches end of life on 31 December 2026. The active support dates for 7.4, 8.0 and 8.1 are two years after each initial release, as php.net’s support cycle defines; the end-of-life page lists their final dates.

Check which PHP version your site runs

• WordPress dashboard: go to Tools → Site Health → Info and open the Server section. It shows the PHP version serving your site.
• Hosting control panel: check the version set for the exact domain. In cPanel this is Software → MultiPHP Manager (cPanel documentation). A server-wide default can differ from the domain’s own setting.
• From outside: our free PHP version checker looks for a PHP version the server exposes publicly. Many servers hide it, so “not detected” means unknown, not safe.
• Command line: php -v reports the command-line PHP, which can differ from the version serving web pages. It matters if your scheduled tasks run through a system cron job.

If the answer is 8.2, you have a deadline. If it is 8.1 or older, the site is already on an unsupported branch and the plan below is urgent.

Before you pick a target, run the free WordPress PHP Upgrade Readiness Checker. Paste your Site Health report (Tools → Site Health → Info → Copy site info to clipboard) and it flags core-version conflicts, stale or unknown plugins and missing rollback steps, then builds a staging test plan. The report is analyzed in your browser.

Which version to move to: PHP 8.3, 8.4 or 8.5?

Pick the newest branch that your WordPress version, your host and every business-critical plugin support, and prove it on staging. Our rule matches the recommended PHP version guide:

• PHP 8.5 first: on WordPress 6.9 or later, when your host offers it, your critical plugins support it and staging is clean.
• PHP 8.4 as the fallback: when a plugin, theme, integration or host is not ready for 8.5.
• PHP 8.3 as a short stop: only when a documented blocker rules out both, with a date set to move again.

Core support comes from the WordPress compatibility matrix; security dates come from php.net. Why the right answer depends on your stack:

• WordPress version: if the site runs an older WordPress, update WordPress on staging first. The target PHP version must be supported by the WordPress version you will actually run.
• Plugins and theme: premium plugins, page builders, WooCommerce extensions and custom themes often lag behind WordPress core. One blocker can decide the branch.
• Host: the target must be available on your plan, with the extensions your site uses. PHP 8.4 moved IMAP, OCI8, PDO_OCI and PSpell out of the PHP distribution into PECL, so a plugin that reads a mailbox through IMAP needs your host to add that extension separately.
• Custom code: snippets in functions.php, a child theme or a custom plugin get no vendor updates. Someone has to check them.
• Runway: PHP 8.3 is already in security-only support and reaches end of life on 31 December 2027. Choosing it means planning the next upgrade within a year.

For branch-specific checks, see WordPress and PHP 8.5 and WordPress and PHP 8.4.

What changes between PHP 8.2 and your target

The official migration guides list every change. These are the ones most likely to surface in WordPress plugin and theme code:

• PHP 8.3 is the smallest step. It deprecates only a handful of behaviors, such as calling get_class() without arguments (PHP 8.3 deprecations).
• PHP 8.4 deprecates implicitly nullable parameter types, a pattern common in older plugin code where a typed parameter defaults to null, such as Type $value = null (PHP 8.4 deprecations). It also unbundles the IMAP extension, as above.
• PHP 8.5 deprecates functions older plugins call routinely, including curl_close(), imagedestroy() and finfo_close(), because PHP frees those objects automatically. It also deprecates the backtick shell operator and non-canonical casts such as (integer) (PHP 8.5 deprecations).

Deprecations write notices to the log; they do not stop the site. They still matter: they point to code that a future PHP version may break, and a log full of notices hides the errors you need to see. Fatal errors are what take pages down, usually caused by a missing extension, removed functionality or code that was already fragile.

Step-by-step WordPress PHP upgrade plan

1. Take an inventory and a backup you have restored

Write down what the site runs before you change anything:

• WordPress version, active theme and child theme;
• every plugin with its version, including inactive and must-use plugins;
• custom code: functions.php changes, code snippet plugins and custom plugins;
• PHP extensions and limits such as memory and upload size, from your hosting panel (our guide to PHP extensions for WordPress explains which ones matter);
• integrations: payment gateways, CRM, email sending, form services, backups and scheduled imports.

Then back up the files and the database and store the copy off the server. A backup only counts once you have restored it successfully somewhere, and staging is the ideal place to prove it.

2. Build a staging copy that matches production

• Use the same WordPress, theme and plugin versions, the same PHP extensions and similar limits.
• Password-protect staging so search engines and customers cannot reach it.
• Stop real side effects: send staging email to a test inbox, switch payment gateways to test or sandbox mode, and pause integrations that write to live systems such as CRM, stock or accounting.
• Update WordPress, the theme and plugins on staging while it still runs PHP 8.2, and check the site. You then test the versions you will actually run, and any new error after the PHP switch clearly comes from PHP. Apply the same updates to production before or together with the switch.

3. Check plugin, theme and custom-code compatibility

• Vendor evidence: read the changelogs and support pages of your theme and critical plugins for statements about PHP 8.3, 8.4 or 8.5. A plugin’s “Requires PHP” value is only the minimum version it needs, not proof that it works on newer ones.
• Maintenance signals: plugins without recent releases, or ones closed on WordPress.org, are the usual blockers. Plan replacements early, because swapping a plugin usually takes longer than the PHP switch itself.
• Static scan of custom code: run PHP_CodeSniffer with the PHPCompatibilityWP ruleset against your custom theme and plugins, with testVersion set to your target. Use its 3.x development release: the last stable PHPCompatibility release, 9.3.5, dates from December 2019, before PHP 8.0 existed.

composer require --dev \
  phpcompatibility/phpcompatibility-wp:"^3.0@dev"

vendor/bin/phpcs -p wp-content/themes/your-theme \
  --standard=PHPCompatibilityWP --extensions=php \
  --runtime-set testVersion 8.4

A static scan finds removed and deprecated functions and syntax problems. It cannot run your checkout, so it supports testing rather than replacing it.

• Logs on staging: switch staging to the target version and turn on WordPress debug logging in wp-config.php, as described in Debugging in WordPress:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Errors, warnings and notices then go to wp-content/debug.log instead of the screen. Read it together with the server’s PHP error log after every test and sort what you find: fatal errors block the upgrade, warnings need a closer look, deprecations go on the to-do list. WordPress recommends these debug settings for local and staging sites, not live ones, so switch them off and delete the log when you finish.

4. Test the paths that earn you money

A homepage that loads proves very little. On staging, go through every path your customers and team rely on, and watch the logs while you do:

For scheduled jobs, WP-CLI helps: wp cron event list shows what is scheduled and wp cron event run --due-now runs everything that is due (WP-CLI documentation). Elementor sites should also follow our Elementor and PHP test plan.

5. Switch PHP on the live site

• Choose a quiet time when someone can test straight away and roll back if needed.
• Take a fresh backup immediately before the change.
• Change the PHP version for the domain in your hosting panel, or ask your host to change it for that exact site.
• Confirm the new version in Tools → Site Health → Info → Server. If scheduled tasks run through a system cron job, check which PHP binary that job calls.
• Repeat the critical tests from step 4 on the live site. For payments, a small real order that you then refund confirms the live gateway works.

6. Monitor after the switch

• Check the server’s PHP error log daily for the first week.
• Confirm that scheduled work actually ran: backups, renewals, imports and feeds.
• Compare form submissions, orders and sign-ups with a normal week. A quiet drop is often the first sign of a broken form or payment callback.
• Make sure the WordPress admin email reaches a person who acts on it. Since WordPress 5.2, a fatal error in a plugin or theme sends that address an email with a recovery mode link.

7. Keep a rollback plan ready

• Decide before the switch what triggers a rollback, for example a checkout that fails and cannot be fixed quickly.
• Switching PHP back is usually one setting in the hosting panel, as long as your host still offers PHP 8.2. After 31 December 2026 it may not, which is one more reason to finish before then.
• If plugin updates changed the database, switching PHP alone may not undo it. Restore the backup from step 5 instead.
• Keep the pre-upgrade backup until the site has run cleanly through a full business cycle: a month-end, a newsletter send, a subscription renewal date.
• Write down what changed, what you tested and what is still open. That record makes the next upgrade faster, and sites that stop at PHP 8.3 will need one in 2027.

Get help with a WordPress PHP upgrade

Our WordPress support service can assess compatibility and help plan a safe upgrade. We review your core, theme, plugins, custom code and hosting before agreeing the scope and price. The agreed work can include a staging test, backups, checks of business-critical paths, a rollback plan and a record of the changes.

A suitable, limited task may fit the existing $555 Website Fix Sprint. That is one example of scoped sprint work, not a promise to resolve every legacy-site issue for one price. Replacing abandoned plugins, rewriting custom code or recovering a compromised site may need a separate scope. Monthly care plans cover ongoing maintenance; they do not automatically include this one-off work.