PHP 8.2 End of Life on 31 Dec 2026: WordPress Upgrade Plan

What actually happens on 31 December 2026

Every PHP branch follows a published lifecycle: two years of active support, when both bugs and security issues are fixed in regular releases, followed by two years of security-only support, with releases shipped only when needed. After those four years the branch reaches end of life (EOL) and receives no fixes at all.

PHP 8.2 was released on 8 December 2022. Active support ended on 31 December 2024, so for almost two years it has been getting critical security fixes only, not ordinary bug fixes. On 31 December 2026 that last phase ends too. Here is where the recent branches stand, according to php.net:

Nothing switches off on 1 January 2027. Your site will serve pages exactly as it did the day before. What changes is that any vulnerability discovered in the PHP engine from then on will have no official fix for the 8.2 branch. If you are still on PHP 8.1 or older, you are already in that position: the plan below applies to you too, with a bigger jump.

The real risks of staying on PHP 8.2

• Security exposure: php.net warns that users of end-of-life branches may be exposed to unpatched security vulnerabilities. The risk does not spike on day one; it grows every month you stay.
• Stuck plugins and themes: developers keep raising their «Requires PHP» value. When a new plugin release needs a newer PHP than yours, WordPress tells you the update does not work with your version of PHP and hides the update button. You stay on an old release, bugs included.
• Frozen dependencies: frameworks and Composer packages declare a minimum PHP version; falling behind blocks updates across the whole dependency tree.
• Hosting availability: after EOL, some hosts remove unsupported versions from their control panels or keep them only for a limited time. Ask your provider what they plan to do, and when.

How to check which PHP version your site really runs

One server can run several PHP versions side by side: one for the website, another for the command line, sometimes a different one per domain. The version that matters is the one actually serving your pages.

1. WordPress dashboard: Tools > Site Health > Info > Server. It shows the PHP version used by the web server, plus key limits.
2. cPanel: open MultiPHP Manager. The list shows each domain's version. If a domain says «inherit», it follows the server default set by the administrator, which can change without you touching anything.
3. Plesk or a custom host dashboard: look at the PHP settings of the individual domain, not the account-wide defaults.
4. No panel at all: drop in a temporary file that prints only PHP_VERSION, load it in the browser and delete it straight away. Do not leave a phpinfo() page online; it reveals far too much about the server.

# Command-line PHP: may differ from what your website uses
php -v

# PHP binary and version used by WP-CLI (also command-line PHP)
wp cli info

# Composer projects: which packages block a move to PHP 8.4
composer why-not php 8.4

WordPress, plugins and themes on PHP 8.3 and 8.4

WordPress core is rarely the problem, as long as it is up to date. WordPress officially recommends PHP 8.3 or newer, and the core compatibility table sets these thresholds:

Since WordPress 7.0, core needs at least PHP 7.4. But «compatible» describes core only: real breakage almost always comes from plugins, themes, page builders and custom code. In a plugin readme, «Requires PHP» is just the minimum version, while «Tested up to» refers to the WordPress version, not PHP. There is no official field stating the highest PHP version a plugin has been tested on, so you only find out by testing or by asking the developer.

What changes in the code from 8.2 to 8.3 and 8.4

• PHP 8.3 has a short, targeted list of backward-incompatible changes: for instance, range() now throws errors on invalid arguments and number_format() honours negative decimals.
• PHP 8.4 deprecates implicitly nullable parameter types, such as function foo(Type $a = null) without a question mark before the type. It is the most common pattern in older code and triggers deprecation notices, not fatal errors.
• In 8.4, some extensions were unbundled from PHP and moved to PECL, including IMAP and PSpell. If a plugin reads mailboxes over IMAP, confirm the extension is still installed on your server.
• Also in 8.4, the E_STRICT constant, trigger_error() with E_USER_ERROR, and mysqli_ping(), mysqli_kill() and mysqli_refresh() are deprecated.

Choosing a target: 8.3, 8.4 or 8.5?

If you are upgrading now, make the jump count. PHP 8.3 is already security-only and reaches end of life on 31 December 2027, so you would be back here in a year. PHP 8.4 is covered until 31 December 2028 and supported by WordPress core since 6.7; in our view it is the safest bet for most sites. PHP 8.5 runs until 2029, but it is the youngest branch: go for it when your stack is recent and your tests prove it works.

Step-by-step upgrade plan with staging

1. Inventory: for each site, record the PHP version, WordPress version, theme, active plugins and premium licences. A plugin with an expired licence often cannot be updated, and that can stall the whole plan.
2. Take a full backup of files and database, and verify it by restoring it at least once somewhere else.
3. Update core, theme and plugins while still on the current PHP version, so update problems and PHP problems do not get mixed up.
4. Build a staging copy that mirrors production: same PHP extensions, same memory limits, same web server. Block search engines and disable real outgoing email and payment webhooks.
5. On staging, enable WordPress error logging (snippet below) and switch PHP to 8.4.
6. Test the critical paths: home and key landing pages, login and dashboard, block editor and page builder, contact forms, search, cart and checkout in test mode, media uploads, scheduled tasks and the backup plugin.
7. Read wp-content/debug.log and the server's PHP error log. Split fatal errors, to fix now, from deprecations, to schedule.
8. Fix what you found: update or replace problem plugins, ask developers for patches, correct custom code. In Composer projects, run composer check-platform-reqs against the new PHP version.
9. Pick a low-traffic window, get the client's sign-off and take a fresh backup right before the switch.
10. Change the PHP version in production, purge the page cache and the CDN cache, then repeat your key tests.
11. Watch the logs and scheduled tasks over the following days: some issues only surface with overnight cron jobs or traffic peaks.

// wp-config.php, STAGING ONLY: above the "That's all, stop editing!" line
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );       // writes to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );  // no errors in the page output
@ini_set( 'display_errors', 0 );

Rolling back without making things worse

Switching PHP back to the previous version from the control panel takes seconds, which is why this kind of upgrade can be done while keeping disruption to a minimum. Going back to 8.2, however, does not undo everything else that happened in between.

• If you installed newer plugin versions along the way, they may have changed the database. To truly return to the previous state, you need to restore the database backup as well.
• On an online shop, restoring the database means losing orders and sign-ups received after the backup. Agree in advance who decides, and for how long a rollback is still acceptable.
• Write down your rollback trigger before you start, for example a fatal error on checkout or login that you cannot fix within an agreed time.
• Treat a rollback to 8.2 as temporary: after 31 December it only buys time, it is not a destination.

Checklist for agencies managing many sites

• One sheet listing every site: current PHP version, planned switch date, owner.
• Target PHP 8.4 everywhere by December; keep 8.3 only as a fallback for sites with a documented blocker and a date to clear it.
• Prioritise online shops, membership areas and sites running plugins that have not been updated in a long time.
• Check premium theme and plugin licences before you start, not halfway through.
• Tell clients what is changing, when, and who to contact if something looks off.
• Domains set to «inherit»: pin an explicit version so a change to the server default does not catch you out.
• Once done, note the next deadline in your maintenance agreement: for PHP 8.4 it is 31 December 2028.

If you would rather hand this off, the lubemy team can work through the inventory, staging and version switch with you, site by site. Either way, the calendar is fixed: the deadline is 31 December, but testing should start now.