PHP 7.4 is end of life. What that means for your online store

PHP 7.4 reached end of life on November 28, 2022. Since that day the PHP project has released no security fixes for it at all. If your store still runs on 7.4, every PHP vulnerability found since then is still open on your server. Your host may promise to patch everything, but that promise doesn't cover the language your store is written in.

We have been building web software since 1998 and have watched a lot of PHP versions retire. What sets 7.4 apart is how many online stores are still on it years later. Below we look at how that happened, why it matters more for a store than for a brochure site, and how to move off it without breaking anything.

How stores got stuck on 7.4

Nobody chooses to run end-of-life software. Stores end up there because most of the cost of the upgrade has nothing to do with the PHP version itself.

Change PHP on a store and everything running on it has to work with the new version: the platform, the theme, each plugin or module, and the custom code someone wrote in 2017 and never touched again. If one abandoned module uses a function that has been removed, the checkout throws an error. So the upgrade gets postponed until after the busy season, then until after the redesign. Three years later the host is sending warnings and the store is still on 7.4, with a wider gap to close than before.

That gap is the real problem. A store on PHP 7.4 is usually a store nobody has been responsible for.

What end of life means in practice

The obvious part is security. Vulnerabilities in PHP itself are published regularly, with details. On a supported version they are patched within days, while on 7.4 they stay open. A site that takes payments and holds customer addresses is far more exposed to that than a blog.

Your platform and plugins will also stop supporting you. WooCommerce, WordPress, PrestaShop and the people who write their extensions drop old PHP versions over time, and at some point the current version of your platform won't install on 7.4. From then on you can't apply the platform's own security updates either, so two layers of the store are frozen instead of one.

Hosts don't wait forever. They retire old PHP builds, some of them with a short warning, and the first you hear of it is a white screen on a Monday morning. Others keep 7.4 alive as a paid "extended support" option, which is a monthly fee for staying exposed.

And the store is slower than it needs to be. Each PHP release since 7.4 has been faster than the last. In the stores we fix, the PHP upgrade alone almost always wins back a measurable part of the speed before any other work, and in most of them outdated software is the biggest single reason the store is slow.

Why you shouldn't just flip the switch

Most hosting panels let you change the PHP version from a dropdown. On a store with thirty plugins or modules and a customized theme, don't do that on the live site. When it goes wrong, the home page often still loads, because it uses very little code. The error appears at checkout, where the payment module runs code nobody has touched in years, and you find out when the orders stop.

The safe order is the same as for any upgrade on a store that is earning money. It starts with an inventory of every plugin or module, its version and whether its author still maintains it, plus every piece of custom code. That list decides how much work the upgrade is, and most stores don't have one.

Next comes bringing the platform and its extensions up to date. Current versions support current PHP and old ones don't. Upgrading PHP under old plugins is the step that breaks stores. Updating the plugins first is what makes the PHP change uneventful. Anything abandoned is dealt with here too: if it matters to your business it gets rewritten, and if it only costs you page speed it gets removed.

The PHP change itself happens on a staging copy. We switch PHP there, test the whole purchase path and fix what breaks, and only then plan the cutover on the live store, with a backup taken first and a way back. After that the store stays current, with updates applied on a schedule and tested on staging before they reach the store, so a three-year gap never builds up again.

How much work is it?

It depends entirely on the inventory. A store on a standard theme with a modest number of maintained plugins is a day or two of careful work. A store with years of custom code, abandoned modules and a theme nobody can rebuild is a project. There is no honest way to quote that without looking, which is why we never do.

Our way in is a free store review. There is no charge and no obligation, it takes 3 business days from receipt of access, and it gives you written findings ranked by business impact, including the inventory above. It also tells you which of two paths you are on. If the store can move to a current PHP and onto our servers with modest work, we do that, and from then on it runs on a monthly plan. If it needs a full Store Rescue, the review comes with a fixed quote. The rescue includes the PHP upgrade, the platform upgrade, sorting out the plugins or modules, the database work and the move onto a server we manage, in 30 working days.

Staying current afterwards

Stores end up on end-of-life PHP because nobody was paying attention between emergencies, and that is what a maintenance plan is for. Ours puts the store on a dedicated server we manage. We apply platform, plugin and module updates on a schedule, take daily backups, watch uptime and security, and send a monthly report of what changed and why. It costs from $395 a month, month to month, with no minimum term. The next PHP end of life will arrive on schedule, and on a maintained store it ends up as a line in the monthly report.

The plans are on the maintenance page, with a separate page for WooCommerce and for PrestaShop. If you aren't sure which PHP version your store is on, your hosting panel will tell you, and so will the review.