← All posts

PHP 8.2 Reaches End of Life on 31 December 2026: Check Your Version Now

PHP 8.2 stops getting security fixes on 31 December 2026. How to check which PHP your site runs, find the deprecation warnings and move up safely.

A laptop and a small server on a workbench beside a wall calendar with one day circled in red, a spanner and screwdriver laid out ready for maintenance

Every winter I tell people to check their boiler before the first cold snap, not during it.

Websites are the same. Only quieter. Until they aren't.

Here's the date to put in the diary: PHP 8.2 reaches end of life on 31 December 2026. After that, the PHP team stops releasing security fixes for it. Your site won't fall over on New Year's Day. It just stops getting patched, and that's worse, because nobody notices.

The official dates are on the PHP supported versions page. As I write this, 8.3 gets security fixes until the end of 2027, 8.4 until the end of 2028 and 8.5 until the end of 2029.

Step 1: find out what you're actually running

You'd be amazed how many business owners don't know. Not their fault. Nobody tells you.

  • On shared hosting, look in your control panel. Most hosts, Hostinger included, show the PHP version and let you change it from a drop-down.
  • On a server or your own machine, run php -v in a terminal.
  • From inside the site, a one-line test file does it: <?php echo PHP_VERSION, PHP_EOL;

Delete that test file afterwards. There's no reason to tell the whole internet your version number.

If you'd rather your code checks for itself, version_compare(PHP_VERSION, '8.3.0', '<') returns true on anything older than 8.3. On 8.2.29, for example, it returns true. Time to plan.

Step 2: let PHP tell you what will break

This is the bit people skip, and it's the bit that matters most.

PHP doesn't usually remove something without warning. It deprecates it first, which means it still works but PHP writes a "Deprecated" message every time it runs. Those messages are your free to-do list.

The catch: if the messages aren't being logged anywhere, nobody reads them. So switch logging on in your php.ini, or the PHP settings in your hosting panel, not in the code itself:

  • error_reporting = E_ALL
  • display_errors = Off (visitors should never see errors)
  • log_errors = On
  • error_log set to a file outside your public folder

Why not just put ini_set() at the top of a script? Because some deprecations are raised while PHP is still reading the file, before your first line of code runs. I tested it. The setting in php.ini caught the warning. The ini_set() in the same file missed it.

In my book, PHP Done The Correct Way, the chapter on modernising old code puts it simply: log deprecations in production first, then upgrade. Fix what the log tells you, not what you guess.

Step 3: the classic one you'll probably find

Here's the warning I see most on older code moving to 8.4 or 8.5. A function like this:

function greet(string $name = null): string

works, but on PHP 8.4 and 8.5 it logs: Implicitly marking parameter $name as nullable is deprecated, the explicit nullable type must be used instead.

The fix is one character:

function greet(?string $name = null): string

Same behaviour, no warning. Call greet() with no argument and it works exactly as before.

The full list of changes for each version is in the official migration guides: 8.3, 8.4 and 8.5.

Step 4: move up in the right order

  1. Take a full backup of files and database.
  2. Copy the site to a staging area, or test locally.
  3. Switch the copy to the new PHP version.
  4. Click through every page that takes money, bookings or enquiries. Those are the ones that matter.
  5. Read the error log, fix, repeat.
  6. Switch the live site, then watch the log for a week.

If you can, go straight to 8.4 or 8.5 rather than stopping at 8.3. You'll buy yourself years, not months.

Why bother?

Because an unpatched website is an open back door with a sign on it. And because on a small, tidy site the upgrade is often an afternoon or two of careful work, not a rebuild.

I've got a simple rule: if it makes money, it makes sense. Your website takes enquiries and bookings. Keeping it patched protects that. Two months is plenty of time, as long as you start now and not on Boxing Day.

Which version is your site on? Have a look tonight. It takes about thirty seconds.

If you'd like the longer version, with tested examples, the PHP Done The Correct Way book page has the details.

Let's talk More posts