← All guides

PHP 7 in 2026: what is at risk and how to move off it

PHP 7.1 stopped getting security fixes in December 2019. We still scan live business sites running it. Here is what that exposes, what breaks when you upgrade, and the order that gets you to a supported version without a dead site.

16 September 2026, 3 min read. From a scan in September 2026 of an established company site that scored 29 out of 100, with PHP 7.1 doing most of the damage.

We recently scanned a well-established company site and the server answered with PHP 7.1.14 in its headers. That version dates from early 2018. Nobody had touched the setting since, and nothing looked broken, so nobody had a reason to.

Why a version number matters

PHP is the language WordPress, Laravel and most of the web run on. Each version gets bug fixes for two years and security fixes for a third, then nothing. After that, every hole found in it is public and stays open.

  • PHP 7.1: security fixes ended December 2019
  • PHP 7.4: November 2022
  • PHP 8.0: November 2023
  • PHP 8.1: December 2025

In September 2026, versions 8.2, 8.3 and 8.4 are supported. Anything starting with 7 has been unpatched for years.

The version alone does not mean a site is hacked. It means that when a hole in that version is exploited, there is no fix to install. It also means WordPress itself and the plugins you rely on stop supporting it, so you end up frozen on old plugin versions too, and those are where the actual break-ins come from.

Why the site still works

Because nothing forces the issue. The host keeps the old version available, WordPress stops updating past a certain point but keeps serving pages, and the warnings go to a log nobody reads. From the outside it looks fine. The site we scanned got a 29 because the PHP version, the WordPress version it was stuck on and the missing security headers all came from the same years of nobody looking.

It also costs speed. PHP 8 runs a typical WordPress page a good deal faster than 7.1 on the same server, in most benchmarks somewhere between a third and a half again as fast. For an old site it is the cheapest performance gain available.

What breaks when you upgrade

Real things, not scare stories:

  • Old plugins and themes. Anything not updated in years likely uses functions removed in PHP 8. The site shows a blank page or an error the moment you switch.
  • Custom code in the theme. Functions files written in 2016 often have this problem. The errors are usually small and quick to fix, but there can be many.
  • Old libraries bundled inside plugins. A plugin can be “updated” and still ship a ten-year-old PDF or image library inside it.

None of this is a reason not to upgrade. It is the reason to upgrade on a copy first.

The order we use

  1. Copy the site to staging. Most hosts have a button for this. If yours does not, that tells you something about your host.
  2. On staging, update WordPress, every plugin and the theme as far as they will go on the current PHP. Note anything whose author has not updated it in over two years. Those are the ones that will fail.
  3. Switch staging to PHP 8.2. One version at a time is safer than jumping straight to 8.4. Open every kind of page: home, a post, a product, checkout if there is one, the contact form, the admin screens.
  4. Read the error log, not only the pages. Deprecation warnings tell you what will break in the next version.
  5. Replace what fails. For an abandoned plugin there is nearly always a maintained one that does the same job. For custom code, fix it. This is the step that takes the time.
  6. Move to 8.3 and repeat the checks. Then do the same on the live site at a quiet hour, with the staging copy as the map and a fresh backup as the safety net.
  7. Turn on the automatic updates you can trust, so nobody has to do this from four versions behind again.

For a typical small business site this is a day of work. For a site with a shop and twenty plugins it can be a week. Either is cheaper than the cleanup after the break-in, which is how we usually meet these sites.

Our scanner reads the PHP version straight from the server’s headers when the server exposes it. If yours shows a 7, that is the first thing to fix.

See where your own site stands.

The scanner checks the things this guide talks about, in about ten seconds, no signup.

Tell us about the site.

A straight answer and a fixed quote, usually the same day.