No error. No warning. The site was “up”. It just wasn’t the site we thought we had.

How many caches are between you and your visitor?

On a typical managed WordPress site there are at least four, and they don’t talk to each other:

1. Browser cache on the visitor’s device. You can’t clear it. You can only tell it when things change.
2. CDN / edge cache (Cloudflare and friends). Caches images and scripts for sure; sometimes whole pages if someone turned on “cache everything”.
3. Server-level page cache — NGINX, LiteSpeed or Varnish in front of the web server. Invisible from inside WordPress. Often has no button you can see.
4. WordPress page cache — a plugin writing finished HTML to disk so PHP doesn’t run for every visitor.
5. Object cache — Redis or Memcached holding database results. This one caused a second, stranger bug on the same site: a plugin we activated stayed “active” in the admin while the cached list of active plugins told WordPress not to load it. Nothing ran until the cache was flushed.

Our stale homepage was layer 3. The WordPress cache plugin had already been cleared; the server in front of it hadn’t, and it kept serving a copy it had saved when the WordPress plugin was still running. The only fix was a button in the hosting control panel that no “Clear cache” link inside WordPress ever touched.

Why this is a business problem, not a technical one

Every “we changed the phone number on the website” that a customer later says they didn’t see. Every price update that didn’t take. Every “the site still shows the old promotion” conversation. Caching is the first thing to rule out, and almost nobody does, because it’s invisible unless you know to look at headers and timestamps.

How to check your own site in one minute

• Open your homepage in a private/incognito window and add ?x=1 to the end of the address. If the page with ?x=1 differs from the page without it, something upstream is serving a stale copy.
• View the page source (right-click → View Page Source) and search for the word “cache”. Many cache layers leave a dated comment at the top or bottom.
• Make a small, obvious edit — a word in the footer — and check it from your phone on mobile data five minutes later.

When we take a site onto Site Care the first job is a map of exactly which caches sit in front of it and how each one is cleared — then we clear all of them, in order, every time you ask for a change. Edits go live when you expect them to. That’s the whole job.

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.