PHP 7.2

7.2 released 30 November 2017, latest 7.2.34.

PHP 7.2 reached end of life on 30 November 2020.

What changed

PHP 7.2 added the object type declaration, the sodium extension for modern cryptographic operations, and Argon2 password hashing support. It also introduced language and runtime refinements such as trailing commas in grouped namespace imports and more consistent handling of numeric keys when arrays and objects are converted. The cycle began deprecating several older mechanisms, including the mcrypt extension, __autoload(), create_function(), each(), and mbstring function overloading, signalling that applications using them needed replacement work before later PHP upgrades.

What staying costs

PHP 7.2 has reached end of life, so upstream no longer provides security fixes or bug fixes for the runtime. A newly discovered interpreter, extension, or bundled-library vulnerability may therefore remain unpatched unless an operating-system vendor applies its own backport. The larger migration risk is accumulated compatibility debt: code that still relies on features deprecated in this cycle can fail on later PHP versions, while dependencies, framework versions, operating-system packages, and deployment images increasingly stop testing or distributing PHP 7.2. Keeping it can also prevent adoption of supported library releases and modern security controls.

What to do

Inventory every PHP runtime, CLI job, web worker, extension, framework, and Composer dependency that is pinned to PHP 7.2. Run the application test suite with deprecation reporting enabled, then replace uses of mcrypt, __autoload(), create_function(), each(), and mbstring function overloading with supported alternatives. Update Composer constraints and dependencies for a currently supported PHP 8.x target, and use static analysis plus automated compatibility tooling to identify changed language behaviour. Test representative production workloads in an isolated environment, including authentication, encryption, serialization, database access, background jobs, and error handling. Deploy the upgraded runtime through a staged rollout with rollback capability, and remove PHP 7.2 images and packages once workloads have moved.

We can tell you what moving off PHP 7.2 involves.

What it takes to move off PHP 7.2 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