PHP 8.2 end of life: what 31 December 2026 means for your sites

PHP 8.2 reaches end of life on 31 December 2026. After that date the PHP project stops publishing security fixes for it, so any vulnerability found in PHP 8.2 itself stays open on every server still running it. The site keeps working; it just stops being patched.

For a single app that is one upgrade. For an agency looking after thirty WordPress sites across four hosts, it is a project with a deadline, and the time to start it is before the hosting companies start forcing upgrades on their own schedule.

The PHP support calendar

Each PHP release gets two years of active support and then two years of security-only fixes.

Moving from 8.2 to 8.3 buys only one more year. For most sites PHP 8.4 is the better target: it is mature, widely supported by hosts and plugins, and covered until the end of 2028.

Laravel apps

Laravel 13 already requires PHP 8.3, and Laravel 12 runs on anything from 8.2 to 8.5. So a Laravel 12 or 13 app can usually move to PHP 8.4 with little more than a dependency update and a run of the test suite.

Apps on Laravel 11 or older are the real problem. Laravel 11 lost security support in March 2026, so those apps are unpatched at the framework level already, and the PHP deadline is a good moment to fix both together. Our guide to Laravel upgrade costs covers what that involves at each version.

WordPress sites

WordPress core runs on PHP 8.4 and the project recommends PHP 8.3 or greater. Core is rarely the issue. The risk is in themes and plugins: an old premium theme, a plugin whose developer moved on, or custom code written against PHP 7 habits.

The changes that break things most often are deprecations that became visible in the PHP 8.x series. Dynamic properties on classes were deprecated in 8.2, and PHP 8.4 deprecates implicitly nullable parameter types, such as function save(Post $post = null). Deprecations don't break a site by themselves, but with debug logging on they fill logs, and with display errors on they print warnings onto live pages. Fatal errors come from functions removed outright and from stricter type checks in code nobody has touched in years.

An upgrade checklist for a portfolio of sites

1. Inventory every site with its host, current PHP version, and who can change it. Hosting panels often show the PHP version per site.
2. Take a fresh, tested backup of each site before touching anything.
3. Clone each site to staging and switch staging to PHP 8.4.
4. Turn on error logging (not display) and click through the key pages and forms: checkout, contact forms, logins, search.
5. Run a compatibility scan such as PHPCompatibility for PHP_CodeSniffer against the theme and custom plugins, and read the log for deprecations and fatals.
6. Update or replace any plugin that fails. Plugins with no release in two years are candidates for replacement anyway.
7. Switch production during a quiet period, watch the error log for 48 hours, and keep the old PHP version selectable for a quick rollback where the host allows it.

Done this way, a healthy WordPress site takes an hour or two. Sites with abandoned plugins or heavy custom code take longer, and the inventory in step one is what tells you which sites those are before December.

If you would rather not do it yourself

This is the kind of work a website care plan exists for: PHP and dependency upgrades tested on staging, backups before every change, and monitoring afterwards, done under your agency's name if the sites belong to your clients.