PHP 8.0

8.0 released 26 November 2020, latest 8.0.30.

PHP 8.0 reached end of life on 26 November 2023.

What changed

PHP 8.0 introduced major language features beyond PHP 7.4, including union types, attributes, named arguments, constructor property promotion, the match expression, the nullsafe operator, the mixed type, WeakMap, and throw expressions. It also added a just-in-time compiler, although its benefit depends heavily on the workload and it does not automatically improve typical web-request performance. The release tightened behaviour in several areas: more invalid calls to internal functions raise TypeError or ValueError, some formerly tolerated input now produces errors or warnings, and code using named arguments depends on parameter names as part of an API contract. These changes improve type modelling and make many common patterns more concise, but they can expose assumptions in older applications and libraries.

What staying costs

PHP 8.0 has reached end of life, so the PHP project no longer provides security fixes or maintenance updates for this line. Running it leaves the runtime itself without upstream remediation when defects or vulnerabilities are found, and can create audit, compliance, and incident-response concerns even if the application code is actively maintained. Dependency upgrades become harder as maintained packages, frameworks, extensions, operating-system images, and hosting platforms move their supported PHP ranges forward. The longer a team remains on 8.0, the more likely a later upgrade will combine runtime changes, dependency replacements, and infrastructure changes into one larger and riskier project.

What to do

Plan a move directly to a currently supported PHP release that is compatible with the application's framework, extensions, deployment platform, and vendor dependencies. Inventory every runtime environment, CLI worker, scheduled task, container image, PHP extension, and Composer dependency rather than testing only the main web application. Update Composer constraints and use the target platform setting to identify packages that block the move; replace abandoned dependencies where necessary. Run the full automated test suite and representative production-like workloads on the target version, paying particular attention to deprecated behaviour, stricter parameter and type validation, dynamic-property use, internal-function calls, error handling, and extensions implemented outside the application. Treat named-argument calls to third-party code carefully, because changed parameter names can be a compatibility break. Deploy through a staged environment, monitor logs and error rates, retain a tested rollback path, and remove PHP 8.0 from build and deployment images once the migration is complete.

We can tell you what moving off PHP 8.0 involves.

What it takes to move off PHP 8.0 depends on what you built on it — the version you are on, how much depends on it, and how much of the work is mechanical. Leave your email with this version and we can tell you what that looks like for you.

Not sure yet? Get my plan