Your Hosting Provider Is Trying to Warn You

Key takeaways:

• PHP 7.3 is end-of-life, and sites still running it will be locked out of WordPress updates from April 2025 onward, leaving them without security patches or new features.
• Technical warnings from hosting providers fail because they communicate a version number, not a business consequence — that translation gap is where websites go to stagnate.
• A compatibility audit and PHP upgrade typically costs a few hundred dollars. Falling behind on core WordPress updates compounds into a problem that costs significantly more to fix.

The emails were going to spam, or close enough to it

I had a discovery call recently with a professional services firm based in Raffles Place. Good firm, serious people, well-established client base. Their website had been running fine, no obvious problems, no complaints from anyone internally. But their hosting provider had been sending them emails for months about PHP versions. They’d ignored every single one.

When I looked at their setup, the site was running PHP 7.3.

That’s not a version that needs a minor update. That’s a version that was officially end-of-life in December 2021. The hosting provider had been sending gentle nudges for long enough that the emails had essentially become background noise, the digital equivalent of a smoke detector with a low battery that you keep meaning to deal with.

The problem is not that they were negligent. The problem is that “please update your PHP version” does not, in any meaningful way, communicate “your website is about to become a frozen relic.”

What actually happens when PHP falls too far behind?

WordPress drops support for old PHP versions when the gap becomes a security and compatibility liability. With WordPress 6.9 recently out and the next major version coming, PHP 7.3 support is being cut completely. Sites running that version will be stuck on whatever WordPress version they’re currently on. Indefinitely.

No new WordPress features. No core security patches. No plugin updates that require a current PHP version, which is an increasingly long list.

I’ve been building on WordPress since 2003, back when it was barely a blogging tool and PHP compatibility was something you sorted out by hand in a text editor. The WordPress ecosystem has matured enormously since then, and one of the consequences of that maturity is that the gap between a supported version and an unsupported one has real, compounding consequences. In the early days you could run old software and nothing much happened. The threat surface was smaller, the attack vectors fewer, the plugins simpler.

That’s not where we are now. A WordPress site that can’t receive core security patches is a site with a known, unaddressed vulnerability. Not hypothetically. Known. Because the patches that newer WordPress versions receive also, by implication, tell anyone paying attention what vulnerabilities exist in the versions that didn’t get the patch.

Why do businesses keep ignoring hosting provider emails?

Because the emails are written for someone who already understands the stakes. I don’t say this to be uncharitable to hosting providers. I’ve seen this pattern play out for over two decades, and the problem is structural, not a failure of effort.

An email that says “your server is running PHP 7.3 and support is ending, please upgrade to PHP 8.2 or higher” is technically accurate and completely useless to the majority of people who receive it. The person reading it is a managing director, a marketing manager, or an office administrator. They don’t know what PHP is. They don’t know what “support ending” means in practical terms for their website. They see a technical string of numbers, assume it’s something the IT guy handles, and either forward it to someone or delete it.

The translation gap between “technical warning” and “business consequence” is exactly where websites go to stagnate.

I’ve seen this same gap create problems across 25 years of working with clients in Singapore, Australia, and New Zealand. The hosting provider is trying to help. They’re sending the right information. But information without context doesn’t change behaviour.

What the email should say, and almost never does, is something like: “If you don’t act on this before April, your website will be unable to receive security updates. That means known vulnerabilities in your site’s core software won’t be patched. It also means you’ll fall progressively further behind your competitors who can update.”

That framing changes the calculation. That framing gets forwarded to someone with budget authority.

How bad does the PHP version gap actually get?

PHP 7.3 is not just one version behind. It is multiple major versions behind. PHP 8.0, 8.1, 8.2, and 8.3 have all shipped since PHP 7.3 went end-of-life. Each of those releases included performance improvements, security fixes, and changes to how the language handles certain operations.

The practical impact on a WordPress site falls into a few categories.

First, plugin and theme compatibility. Plugin developers write against supported PHP versions. When you’re running PHP 7.3, you’re relying on plugin developers to maintain backward compatibility with a version that is years out of date. Some do. Many have stopped. This means you either can’t update plugins at all, or you update them and things break, which trains your team to stop updating plugins, which makes the underlying security problem worse.

Second, performance. PHP 8.x is meaningfully faster than PHP 7.3 for most WordPress workloads. Not marginally faster. Measurably faster, which matters for page load times, which matters for how Google treats your site, which matters for whether people actually stay on the page long enough to become a lead.

Third, the compounding problem. The longer you wait, the larger the gap becomes. A PHP upgrade from 7.3 to 8.2 done today requires a compatibility check and some testing. The same upgrade done in eighteen months, after WordPress has moved further ahead and your plugins have accumulated more changes, is a substantially larger piece of work. The $600 job becomes a $3,000 job not because the technical task is fundamentally different, but because the debt has accumulated.

What does a PHP upgrade and compatibility audit actually involve?

It’s not a big production. For most WordPress sites running on modern hosting, the upgrade itself is a server-level change that takes minutes. The real work is the audit before you flip the switch.

At Chillybin we run through a standard compatibility check before any PHP version upgrade: themes, plugins, custom code, database queries that might behave differently under the new version. We spin up a staging environment that mirrors the live site, upgrade PHP there first, and run through the key site functionality. Form submissions, payment flows if there are any, any custom integrations, the admin experience.

The things that break are usually predictable. Deprecated functions that were removed in PHP 8.x, plugins that haven’t been updated in a long time (which is its own signal worth paying attention to), occasionally custom code written by a previous developer that relied on behaviour PHP no longer supports. Ninety percent of the issues fall into a handful of categories.

For a straightforward WordPress site, the whole process takes a day or two of focused work. The Raffles Place firm I mentioned will come out the other side with a site that can receive WordPress updates again, can update its plugins safely, and is running on a PHP version with an active support window.

The alternative is a site that fossilises. That’s not a dramatic description. It’s what actually happens. The site doesn’t break visibly, at first. It just stops being able to move forward while everything around it does.

Is this only relevant to older WordPress sites?

No, and this is the part that surprises people. I’ve spoken with businesses who had their sites built two or three years ago and assume that means everything is current. It often isn’t.

A site built in 2022 on a budget, handed over with no maintenance plan, could easily still be running the PHP version it launched on. Hosting providers default to stability, not currency. Unless someone specifically updates the PHP version in the hosting control panel, it often stays where it was set at launch.

I’ve audited sites where the hosting environment hadn’t been touched since setup, even though the site itself had been actively used and updated on the WordPress side. The client assumed that hosting was something that just looked after itself. Technically it does, in the sense that the server keeps running. But “still running” and “still current” are not the same thing.

For any business running WordPress in Singapore or anywhere else, the question worth asking your web developer or hosting provider right now is simple: what PHP version is my site on, and when does that version reach end-of-life? If you get a blank look or a vague answer, that’s useful information about whether your site is being looked after.

What should you actually do if you’re in this situation?

Get the audit done before it becomes urgent. That’s the only piece of advice that matters here.

A web developer in Singapore or elsewhere who knows WordPress can tell you within a short assessment what PHP version you’re on, what the upgrade path looks like, and what the risks are if you do nothing. The assessment itself is not expensive. The work to fix a site that has fallen significantly behind is.

The Raffles Place firm I worked with will spend roughly $600 to get their site onto a current PHP version with a clean compatibility check. If they’d acted on the first email from their hosting provider, it might have been simpler still. If they’d waited another six months, the gap would have been wider, the plugin compatibility issues more numerous, and the bill higher.

The hosting provider was not trying to burden them with technical jargon. They were trying to prevent exactly this situation. The gap was in translation, and that’s a gap worth closing as early as possible.

There’s a version of this story where businesses treat hosting emails the way most people treat terms and conditions updates. I understand why that happens. I’d just rather my clients didn’t find out the hard way what the fine print actually meant.

If you’re not sure what version of PHP your site is running, find out today. The answer takes about thirty seconds to get, and it’ll tell you a great deal about the state of what you’ve been ignoring.