We moved a site to PHP 8 and it went down in 30 seconds. Here’s what that costs you.

Last week our own agency site, simpweb.com, went white. Not a slow page. Not a broken layout. A single line of text where the website used to be:

Fatal error: Only files produced by the PHP 8.2 or 8.3 ionCube Encoders can run on PHP 8.3. The file …/plugins/whmcs-bridge-sso/sso.init.php has been encoded for PHP 7.1.

Nobody had touched the site. The hosting server’s default PHP version had been bumped from 7.4 to 8.3, and one plugin — a paid “bridge” that embedded our billing system inside WordPress — was shipped as encrypted code compiled for a PHP version that is now five years old. It could not run. So nothing ran.

Why most sites don’t notice

Here is the uncomfortable part: the site looked fine from the outside. A server-level cache in front of WordPress kept serving a copy of the homepage it had saved earlier. Visitors saw a website. Anyone who clicked to a page that wasn’t cached, tried to log in, or submitted a form hit the error. If we hadn’t been working on the site that day, the first person to tell us would have been a customer — or nobody, and the quote requests would just have quietly stopped.

This is the normal failure mode for a small-business website. It doesn’t explode. It rots in a corner nobody looks at, and the cost shows up weeks later as “it’s been quiet lately”.

What fixing it actually involved

1. Setting PHP back to 7.4 in the hosting control panel so the site came back up — a two-minute change, if you know where it lives and that it’s the cause.
2. Recognising that the plugin was the real problem: encrypted, licensed, and the vendor wanted money for the PHP-8 build. We didn’t want to be held hostage by a plugin for a feature we could do without.
3. Writing a small replacement that redirects every old URL the bridge used to serve to the billing system directly — so nothing anyone had bookmarked or linked broke — and retiring the bridge. That replacement is now a free download.
4. Only then, with the obstacle gone, planning the move to PHP 8 properly, because two other plugins were already refusing to update until we did.

Total time: an afternoon. Total cost to a business that didn’t catch it: a day or a week of lost leads, plus whatever it costs to find someone to look at it in a hurry.

The thing that would have prevented it

Not a better plugin. Someone whose job it is to notice. An uptime check that loads an uncached page every minute and texts us when it fails. A record of what PHP version the site runs and which plugins can’t survive an upgrade. A person who reads the hosting company’s “we’re upgrading PHP” email, because the business owner has a business to run and shouldn’t.

That is literally the product we built after this week. Site Care is us doing those boring things every month for a flat fee, so the first you hear about a problem is the email saying it’s already fixed.

Three things to check on your own site today

• What PHP version are you on? WordPress → Tools → Site Health → Info → Server. If it says 7.4 or lower, you are on borrowed time; hosts are retiring it.
• Do you have any encoded or licensed plugins? If a plugin’s folder is full of unreadable files, it will not survive a PHP upgrade unless the vendor ships a new build — and they may charge you for it.
• Would you know within five minutes if your site went down? If the honest answer is “a customer would tell me”, that is the gap.