Your PHP Version Is a Ticking Clock

Key takeaways:

• WordPress is dropping support for PHP 7.2 and 7.3, meaning sites still running those versions will become vulnerable and eventually stop functioning correctly.
• The upgrade itself takes roughly an hour, but without staging environment testing first, it carries real risk of breaking a live site.
• Paying a developer $400–600 to handle this properly is significantly cheaper than emergency recovery on a site that stops loading for your customers.

The maintenance tasks nobody thinks about until something stops working

I’ve been building websites since 1998. In that time I’ve watched the industry develop a reliable pattern: everyone ignores the infrastructure until the infrastructure ignores them back.

PHP versioning is a perfect example. It’s not glamorous. It doesn’t come up in brand strategy meetings. Nobody has ever asked me, during a discovery call, whether their hosting environment is running a deprecated runtime. But when it goes wrong, it goes wrong loudly. Pages that won’t load. Admin dashboards that throw white screens. Plugins that silently corrupt data because they’re executing against a version of PHP that no longer behaves the way they expect.

The WordPress ecosystem has been moving toward PHP 8.x for years. The deprecation of 7.2 and 7.3 is not a surprise. It’s been telegraphed through official channels, through hosting provider notices, through developer forums. And yet, when my team at Chillybin audited our full maintenance client list last October, we found 12 sites still sitting on PHP 7.3. These weren’t neglected sites. They were active businesses with ongoing maintenance contracts. The problem is that PHP version isn’t something you see when you log into WordPress. You have to go looking for it.

What does PHP deprecation actually mean for a WordPress site?

It means WordPress will stop guaranteeing compatibility with those versions. In practice, what follows is a cascade. Core updates ship with code optimised for supported PHP versions. Plugin developers stop testing against deprecated versions. Security patches get applied to supported environments first, and sometimes only. A site running PHP 7.2 in late 2024 is a site running on infrastructure the entire ecosystem has quietly moved away from.

The WordPress core team doesn’t pull the plug dramatically. What happens is more gradual and, in some ways, more dangerous. Your site keeps loading until one day it doesn’t. A plugin update introduces a function call that PHP 7.3 handles differently than PHP 8.1. A core update assumes a capability that older PHP doesn’t have. An edge case in your checkout process, your contact form, your membership logic, stops working. You might not notice for days. Your customers notice immediately.

I’ve seen this play out more times than I can count. A client rings on a Tuesday afternoon. Their WooCommerce store is showing a white screen on the cart page. They updated a plugin that morning. Rollback doesn’t fix it. The actual problem is two layers deeper: the plugin update was written for PHP 8.0, and the server is running 7.3. The plugin author tested against supported environments. Nobody tested against a deprecated one.

How do you check what PHP version your site is running?

The fastest way is to log into your WordPress dashboard and go to Tools > Site Health. WordPress added this panel a few years back and it surfaces your PHP version clearly. If you’re on 7.2 or 7.3, it’ll flag it as a recommendation to upgrade. If you’re on anything below 8.0, you should at minimum know that and have a plan.

The second method is through your hosting control panel. cPanel, Plesk, and most managed WordPress hosting interfaces give you direct access to PHP version settings. Some hosts, particularly older shared hosting providers, still default new accounts to legacy versions because legacy defaults cause fewer support tickets on day one. The problem surfaces later, and by then most customers have forgotten what the original setup was.

A third option is to install a plugin like Display PHP Version, which puts the information directly in your admin bar. Takes thirty seconds.

When we ran our October audit at Chillybin, we pulled PHP version data across all 100-plus maintenance clients programmatically. Of the 12 running 7.3, several were on hosting setups that had been provisioned years earlier and never touched. The hosting environment had been stable, so nobody had looked at it. Stable and current are not the same thing.

Why can’t you just upgrade PHP and be done with it?

You can. And sometimes it’s completely uneventful. The upgrade itself, at the server level, takes minutes. What takes time is knowing whether your existing codebase will behave correctly under the new version.

PHP 8.x introduced breaking changes relative to 7.x. Functions that were deprecated in 7.4 were removed entirely in 8.0. Argument handling changed. Error handling tightened. Code that was sloppy but functional under 7.3 can produce fatal errors under 8.1 or 8.2. Most well-maintained plugins and themes have handled this. But “most” is not “all”, and a single incompatible plugin can take down an entire site.

This is why staging environments exist. You spin up an identical copy of the live site, upgrade PHP on the staging copy, run through the site systematically, and log what breaks. Then you fix those things before you touch the live environment. The whole process, including testing and fixes, runs roughly an hour if nothing major breaks. If something major breaks, you find out on staging instead of on your live site at 2pm on a Wednesday.

One client I worked with earlier this year had a booking system built on a plugin that hadn’t been updated since 2021. When we tested their PHP upgrade in staging, the booking confirmation emails stopped sending entirely. A function the plugin relied on had been removed in PHP 8.0. We found a compatible alternative, tested it in staging over two days, then pushed to live. Zero downtime. Zero customer impact. If they’d upgraded PHP directly on the live server without staging, they’d have had a broken booking system and no idea why.

Is paying a developer to handle this worth it?

Yes. A developer who knows what they’re doing will charge somewhere between $400 and $600 to handle a PHP upgrade properly. That includes auditing your plugin and theme compatibility, setting up or using an existing staging environment, running the upgrade, testing systematically, and resolving anything that breaks before it affects the live site.

Compare that to the alternative. Emergency developer rates for a site that’s down are typically double standard rates, and that’s before you factor in the revenue impact of downtime. A small e-commerce site doing modest numbers can lose hundreds of dollars per hour during an outage. A service business with a broken contact form is generating zero leads while the site is broken, often without realising it. The $400–600 is insurance. The premium is cheap relative to the claim.

There’s also a compounding risk that often gets overlooked. Sites running deprecated PHP versions are running software that no longer receives security patches from the PHP Foundation. Vulnerabilities discovered in PHP 7.3 after its end-of-life date don’t get fixed. They get published. Your server is running software with known, unpatched security holes, and the information about those holes is publicly available to anyone who wants it.

I’m not raising this to alarm people. I’m raising it because it’s the argument that actually lands when I’m talking to a client who’s hesitating on the cost. The $500 isn’t just about keeping the site functional. It’s about not running exploitable infrastructure.

What should you actually do this week?

Check your PHP version today. Log into WordPress, go to Tools > Site Health, and look at what it says. If you’re on 8.0 or higher, you’re in reasonable shape. If you’re on 7.4, you’re not in immediate danger but you should have an upgrade scheduled before the end of the year. If you’re on 7.2 or 7.3, treat this as urgent.

Contact your hosting provider and ask two things: what PHP version you’re currently running, and what the process is to upgrade. Most reputable hosts have made this straightforward. If your host doesn’t support PHP 8.1 or higher, that’s a separate conversation worth having, but start with the upgrade path.

If you have a developer or agency managing your site, forward this to them and ask where your environment sits. If you’re self-managing and comfortable in the WordPress backend, the Site Health panel will give you what you need to start the conversation with your host.

If the site is complex, has custom code, or runs e-commerce, don’t upgrade PHP directly on the live server without testing first. That’s the one rule. Everything else is manageable.

The sites that end up broken in these situations are almost never neglected. They’re sites that were set up properly at the time, maintained reasonably well, and never had anyone look at the underlying server configuration because nothing had gone wrong. That’s the gap. Infrastructure doesn’t announce that it’s drifting out of currency. It just quietly becomes a liability.

Twenty-five years of this work has made me fairly unsentimental about the boring parts of web infrastructure. PHP versions, database backups, SSL renewals, server software patches: none of it is interesting, and all of it matters more than the font choice on your homepage. The sites that stay reliable are the ones where someone is actually watching the underneath, not just the surface. The surface is easy to see. The underneath is where the real risk lives.