DEV Community

Cover image for PHP 8.2 End of Life: Dates, Risks and How to Upgrade
devTalk
devTalk

Posted on Originally published at dev-talk.com

PHP 8.2 End of Life: Dates, Risks and How to Upgrade

#php #php82 #endoflife #php84

PHP 8.2 stops receiving security fixes on 31 December 2026. Your site will not break on 1 January. What changes is that the next serious PHP vulnerability will be fixed in newer versions only, and 8.2 will stay exposed. If you still run 8.2 in production, you have about two months. That is enough time to upgrade properly, as long as you start by finding out what is blocking you.

The dates

PHP gives each release branch two years of active support (bug fixes and security fixes), then two more years of security fixes only. After that the branch reaches end of life. This is the table from php.net:

Branch Released Active support ended / ends Security support ends
8.2 8 Dec 2022 31 Dec 2024 31 Dec 2026
8.3 23 Nov 2023 31 Dec 2025 31 Dec 2027
8.4 21 Nov 2024 31 Dec 2026 31 Dec 2028
8.5 20 Nov 2025 31 Dec 2027 31 Dec 2029

Note the second column for 8.2: it already lost active support in December 2024. For the past two years it has received security fixes only, and in two months it will receive nothing.

What end of life means in practice

  • No more patches for new vulnerabilities. The latest 8.2 release at the time of writing is 8.2.35. After the end-of-life date, the PHP project stops issuing security fixes for the branch.
  • Your host may move before the deadline. Acquia, for example, set its own cutoff at 1 October 2026 and said it would upgrade remaining PHP 8.2 applications to 8.4 itself. Check your provider's notices, because a forced upgrade you did not test is worse than one you planned.
  • Audits and scanners will flag it. Security scanners and compliance reviews usually treat an end-of-life runtime as a finding by itself.

Which version to move to

The smallest hop is 8.3, but it only buys you one more year (security fixes until 31 December 2027). If you are going to do the work anyway, aim higher:

  • PHP 8.4 is a good default. Security support runs to the end of 2028.
  • PHP 8.5 gives the longest runway (end of 2029). Choose it if your framework and dependencies already support it.
  • PHP 8.3 makes sense only as a stepping stone when something blocks you from going further.

If you use Laravel, look at the php constraint in the framework's own composer.json. On the branch heads I checked, Laravel 13.x requires ^8.3, while 12.x and 11.x require ^8.2. So on Laravel 12 you can upgrade PHP first and Laravel later, but a move to Laravel 13 already means leaving 8.2.

Step 1: find every place that runs 8.2

Production is the obvious one. The forgotten ones are CI images, queue workers, cron containers and staging.

php -v                                   # on every server and container

# what your repo pins
grep -n '"php"' composer.json
grep -rn "php:8.2\|php8.2\|8\.2" Dockerfile* docker-compose* .github 2>/dev/null
Enter fullscreen mode Exit fullscreen mode

Step 2: let Composer tell you what is blocking you

Before changing anything, ask Composer which package would stop you from running a newer PHP:

composer why-not php 8.4.0
Enter fullscreen mode Exit fullscreen mode

I tested this with a package that declares "php": "~8.2.0", and the output points straight at it:

acme/old-lib 1.0.0 requires php (~8.2.0)
Enter fullscreen mode Exit fullscreen mode

Each line is a package you must upgrade, replace, or ask the maintainer about. Two details matter. If your composer.json sets config.platform.php to fake an older PHP, remember to raise or remove it when you upgrade. And composer check-platform-reqs checks the PHP that is actually running, so run it on the new version, inside the new environment.

Step 3: catch deprecations without running the app

The cheapest test is to lint your whole codebase with the new PHP. Linting compiles each file, and some deprecations are raised at compile time. The most common one when moving to 8.4 is the implicit nullable parameter:

function send(string $to, array $options = null): void { /* ... */ }
Enter fullscreen mode Exit fullscreen mode

On PHP 8.4.27 a lint run reports:

Deprecated: send(): Implicitly marking parameter $options as nullable is deprecated, the explicit nullable type must be used instead in nullable.php on line 2
Enter fullscreen mode Exit fullscreen mode

PHP 8.3.6 printed nothing for the same file, which is why this appears only after you move to 8.4. The fix is to add the question mark:

function send(string $to, ?array $options = null): void { /* ... */ }
Enter fullscreen mode Exit fullscreen mode

To check a whole project with the new PHP binary:

find app src -name '*.php' -print0 \
  | xargs -0 -n1 php -d error_reporting=E_ALL -d display_errors=1 -l 2>&1 \
  | grep -v "No syntax errors"
Enter fullscreen mode Exit fullscreen mode

A second one is calling get_class() with no arguments inside a class. Both PHP 8.3.6 and 8.4.27 reported Calling get_class() without arguments is deprecated. Use self::class, static::class or get_class($this) instead.

Linting only finds what the compiler sees. Deprecations that happen when code runs will appear only if that code path executes, so also run your full test suite on the new PHP version with error_reporting set to E_ALL, and read the output.

Step 4: switch the runtime and roll out

  1. Update the Docker base image, for example FROM php:8.2-cli to FROM php:8.4-cli, and rebuild with docker build --pull.
  2. Add the new version to your CI matrix first, and make it pass before touching production.
  3. Check that every PHP extension you need is available for the new version, including ones you install separately. If you build extensions yourself, see the PIE installation guide. Xdebug, for instance, has to be a release that supports your PHP version.
  4. Deploy to staging, then to one production node, then everywhere. Keep the old image tag so you can roll back.

Frequently asked questions

Will my site stop working on 1 January 2027?

No. PHP 8.2 keeps running. You just stop getting security fixes from the PHP project.

Is PHP 8.3 a safe place to land?

It is supported until 31 December 2027, so it is safe for now, but you would be repeating this exercise in a year. If 8.3 is the most your dependencies allow today, use it, and plan the next hop.

My Linux distribution still ships PHP 8.2. Am I covered?

That depends on your distribution's own support policy, not on php.net. Check your vendor's security notices for the exact package version before assuming you are covered.

References

Originally published on DEV Talk.

Top comments (0)