8.4 released 21 November 2024, latest 8.4.24.
PHP 8.4 is currently supported. Active support is scheduled to end on 31 December 2026. It reaches end of life on 31 December 2028.
What changed
PHP 8.4 adds property hooks, allowing properties to define get and set behaviour directly in the property declaration, and asymmetric property visibility, so read and write visibility can differ. It introduces lazy objects through Reflection, intended for deferred object initialization in frameworks and dependency containers. The standard library gains array_find(), array_find_key(), array_any(), and array_all(); mb_ucfirst() and mb_lcfirst(); an object-oriented BCMath API; and a native HTML5 parser in the DOM extension. PDO now exposes driver-specific connection subclasses. PHP 8.4 also adds the #[Deprecated] attribute for marking APIs. For compatibility work, an important change is the deprecation of implicitly nullable parameter types: declarations such as function f(string $value = null) should be written as ?string $value = null or string|null $value = null. Code and dependencies can therefore emit deprecation notices even when their normal behaviour has not changed.
What staying costs
PHP 8.4 remains within its supported window, so staying on it is not inherently an urgent operational risk. The immediate cost is that applications do not receive language, runtime, and library improvements introduced by later PHP lines, and ecosystem packages may eventually raise their minimum supported PHP version beyond 8.4. Teams that leave deprecation notices unaddressed also accumulate upgrade work: deprecated declarations or APIs may continue to run now but require changes before a later upgrade. The greater practical risk is treating support status as a substitute for maintenance. Unpatched extensions, unsupported framework versions, weak test coverage, and a dependency tree that cannot be upgraded can still create security and reliability exposure regardless of the PHP line's status.
What to do
Keep PHP 8.4 patched through the distribution or PHP provider used in production, and confirm that all enabled extensions are built and maintained for the deployed PHP package. Run the full application and test suite with deprecations captured, then replace implicitly nullable parameter declarations and resolve notices from first-party code before addressing dependency updates. Inventory Composer packages, framework requirements, native extensions, and deployment images to identify components that constrain a future PHP upgrade. Add a continuous-integration job for the next intended PHP line, initially allowing failures only as a tracked migration backlog. Use that job to update dependencies, fix type and deprecation issues, and test integration paths such as database drivers, HTML parsing, serialization, and error handling. Adopt PHP 8.4 features only where they improve maintained code; property hooks and lazy objects should be introduced with explicit tests because they affect object access and initialization semantics.
Release history
We can tell you what moving off PHP 8.4 involves.
What it takes to move off PHP 8.4 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
