®PHP End of Life in 2026: the upgrade errors breaking sites, and how to fix them
If your website or application still runs PHP 8.1 or older, it stopped receiving security fixes. The upgrade is not optional any more, and it is where most sites break. Here are the exact errors we see, how to fix each one, and how to migrate without taking your site down. If you would rather hand it to a team that does this every week, that is what we are here for.
First: is your PHP version still supported?
End of life means the PHP project no longer ships security fixes for that version. New vulnerabilities simply stay open. That is a problem for your data, your customers, and for any PCI, SOC 2, or ISO obligations you carry. It is also why hosts now upgrade sites automatically, which is how most outages start.
| Version | Status in 2026 |
|---|---|
| PHP 8.5 | Current, actively supported |
| PHP 8.4 | Actively supported |
| PHP 8.3 | Security fixes only |
| PHP 8.2 | Security fixes end 31 Dec 2026 |
| PHP 8.1 | End of life (no more fixes) |
| PHP 8.0 and older | End of life (no more fixes) |
Support dates follow the official php.net release calendar.
The PHP upgrade errors we fix every week
Most upgrade failures are a short list of recurring errors. If you are staring at one of these, here is what causes it and how we fix it.
Creation of dynamic property is deprecatedWhy: Writing to a property that was never declared on the class. Common in older models, config objects, and plugins that set properties on the fly.
Fix: Declare the property on the class, or add the #[\AllowDynamicProperties] attribute as a stop-gap. On large codebases we automate this with Rector.
Passing null to parameter #1 of type string is deprecatedWhy: Core functions like trim(), strlen(), str_replace() and htmlspecialchars() are being handed null. This is everywhere in legacy WordPress themes and plugins.
Fix: Coalesce or cast at the call site (for example trim($x ?? '')), or patch the source of the null. We add deprecation logging first so we fix the real hotspots, not guesswork.
Implicitly marking parameter as nullable is deprecatedWhy: Signatures like function save(int $id = null). The implicit nullable type is now deprecated and becomes an error in a future release.
Fix: Make the type explicitly nullable: function save(?int $id = null). A quick, safe, automated change across the codebase.
Call to undefined function (removed functions and extensions)Why: APIs that were removed: each() and create_function() (8.0), utf8_encode() and utf8_decode() (8.2), plus the old mysql_* functions and mcrypt extension from earlier versions.
Fix: Replace with supported equivalents: foreach, closures, mb_convert_encoding(), and mysqli or PDO. We swap these out and add tests so they do not creep back.
Composer: your PHP version does not satisfy requirementsWhy: Dependencies (or the framework) require a newer or different PHP line than the server runs, so composer install or update fails and the app will not boot.
Fix: Align the platform PHP, update packages to compatible versions, and lock the platform in composer.json so staging and production match.
White screen or HTTP 500 after the host forced a PHP bumpWhy: Hosting providers (cPanel, Plesk, managed cloud) retire old PHP and move your site automatically. A single fatal error then takes the whole site down.
Fix: We read the real error from the logs (not the blank page), fix or hotfix it, and get you back online, then do the upgrade properly on staging.
Frameworks add their own version floors. Laravel 10 needs PHP 8.1 or newer and Laravel 11 needs 8.2 or newer, WordPress wants a current PHP with up-to-date plugins and themes, and older CodeIgniter, CakePHP, and Yii apps often need a staged migration. We work across all of them, and across plain, framework-free PHP too.
A safe upgrade path (what we actually do)
Upgrading PHP in production and hoping for the best is how sites go down. This is the process we run so the switch is boring, which is exactly what you want it to be.
- 1Inventory the stack: PHP version, enabled extensions, Composer dependencies, and framework or CMS versions.
- 2Stand up a staging environment on the target PHP so nothing is tested in production.
- 3Turn on deprecation logging and crawl the app to surface every warning with a real stack trace.
- 4Run static analysis (PHPStan or Psalm) and automated refactors (Rector) to fix deprecations at scale.
- 5Update dependencies and replace removed functions and extensions, with tests to lock the changes in.
- 6Tune performance: opcache, JIT where it helps, and the slow queries the upgrade exposes.
- 7Deploy with a rollback plan and monitoring, so a surprise is a non-event, not an outage.
Why move now, not next quarter
Security. On an end of life version, every new vulnerability stays unpatched. For anything handling payments or personal data, that is a compliance and reputation risk, not just a technical one.
Performance and cost. Modern PHP is substantially faster than the 7.x line. Upgrading often cuts response times and server bills at the same time, so the work frequently pays for itself.
You lose control of the timing. Leave it, and your host eventually forces the upgrade with little notice, usually at the worst possible moment. Doing it on your schedule, on staging, is far cheaper than doing it during an outage.
A team of developers, ready to fix your PHP problems.
Nowgray is a 41-person engineering team that has shipped software since 2018 for 2,300+ businesses. PHP upgrades, legacy application support, emergency "the site is down" fixes, and ongoing maintenance: send us your stack and we will tell you honestly what it needs.
Prefer to explore first? See software development and API & integrations.
- PHP 8.4 and 8.5 are actively supported. PHP 8.3 and 8.2 receive security fixes only (8.2 until 31 December 2026). PHP 8.1 and anything older are end of life and get no further security patches, so running them is a risk.
- Yes. Emergency PHP fixes are something we do regularly. We read the actual error from the server logs, apply a safe hotfix to get you back online, and then plan the full upgrade properly on staging so it does not happen again.
- It can. Older plugins, themes, and packages often rely on deprecated or removed behaviour. We test the upgrade on a staging copy, fix the deprecations, update the components that need it, and only then ship to production.
- Yes. We support legacy PHP apps and migrate them forward in steps so the business keeps running. Where a jump is large, we move version by version with tests at each stage rather than risking one big bang.
- It depends on the size of the codebase and how many deprecations and removed APIs it hits. A small site can be a couple of days; a large, dependency-heavy application can take a few weeks. We scope it first so you get a clear estimate before any work starts.
- We quote per application after a short audit, because the effort depends entirely on the codebase. You can take a one-off upgrade or an ongoing maintenance retainer. Tell us about your stack and we will come back with a scoped estimate.