PHP 8.4 incompatibility
The language your site is written in moved on. Some of your site didn't.
PHP upgrades are the deepest kind of platform change — beneath WordPress, beneath plugins, at the level of the language itself. When a host flips a site to PHP 8.4 (often automatically, often with one email nobody read), every line of aged code meets a stricter interpreter at once. The wreckage pattern is distinctive, and so is the clean path through.
Same-day diagnosis. Flat quote before any fix.
What’s actually happening
PHP's modern era has been a long tightening: behaviors that generated silent quirks became warnings, warnings became deprecations, deprecations become fatals. Code written loosely a decade ago — and a mature WordPress stack always contains some — runs fine on the PHP it grew up with and dies on 8.4's enforcement. That's why the breakage looks binary: the site didn't degrade, it snapped, the moment the interpreter changed underneath it. The error log fills with deprecation and fatal entries that name the offending files with unusual precision, because these are language-level complaints.
The strategic picture matters as much as the repair: staying on old PHP isn't neutral. Old versions lose security support, hosts surcharge or forcibly retire them, and new plugin versions increasingly assume modern PHP — the compatibility gap grows in both directions while you wait. The professional sequence is staged: test the stack against 8.4 (on staging or with compatibility tooling), fix or replace what fails, then switch — or, when the host has already forced the switch and the site is down, triage in reverse: roll the PHP version back if the host allows it, repair on a copy, then re-ascend deliberately. Either direction, the destination is the same: current PHP, which is faster and safer, without the wreckage.
The usual causes, ranked
After twenty-seven years of these calls, the odds are well mapped. Start at the top.
Deprecated patterns turned fatal
The long-warned constructs finally enforced — aged plugins and themes failing at the interpreter level, loudly and specifically.
Host-initiated auto-upgrades
Hosts retiring old PHP on their schedule, not yours — the site that broke 'by itself' overnight usually met a fleet-wide PHP migration.
The custom-code layer
Old theme functions.php work and bespoke plugins from past developers — code with no vendor to ship a compatible update, needing hands-on repair.
One dependency pinning the whole stack
A single abandoned-but-critical plugin failing on 8.4 and holding the entire site's PHP version hostage.
What you can safely try first
Nothing below can make things worse — that’s the selection criterion. Anything riskier belongs in professional hands, on a backup.
- 1
Confirm the timeline against the host
Check the hosting panel's PHP version and your email for the migration notice. Breakage coinciding with a version flip is this diagnosis, confirmed.
- 2
Capture the fatals
The debug log or host error log after the flip names files and lines with language-level precision — that list is the complete casualty roster.
- 3
Use the rollback as a tourniquet, not a home
If the host panel offers a PHP version selector and the site is down, stepping back a version restores service today — and starts the clock on doing the real ascent properly.
Stop and call when…
- Custom code is on the casualty list — language-level repair of unmaintained code is developer work by definition
- The host has no rollback and the site is down — repair happens under fire, in the emergency lane
- The stack needs staged testing before the switch — staging environments and compatibility passes are the job, not the workaround
From there it’s our job: same-day look, flat quote, and the $229 flat repair covers most cases of exactly this.
Single Error Fix — buy it now, skip the hunt.
One error, hunted down and fixed — 500s, white screens, redirect loops, broken pages.
Covers one specific error or broken behavior on one site. Diagnosis, the fix, and a plain-English note on what happened. If we can't fix it, you get a full refund.
Questions we hear a lot.
Why did my host change my PHP without asking?
They did ask — once, by email, weeks ago, in a message that read like boilerplate. Hosts retire PHP versions fleet-wide because supporting insecure interpreters is a liability they won't carry indefinitely. It's defensible policy with brutal timing. The lesson worth keeping: PHP version is part of your stack, and version-change emails from hosts deserve two minutes of attention.
Is upgrading PHP worth this hassle?
Unambiguously. Modern PHP is dramatically faster — real, measurable page-speed gains — and current versions get security patches while old ones accumulate known holes. The hassle isn't caused by upgrading; it's caused by the aged code the upgrade exposed, which was a quiet liability all along. The upgrade just sent the invoice.
What does the $229 repair include?
The casualty roster from the logs, each item fixed, updated, or replaced (custom code patched where repair-scale, quoted flat where it's larger), the PHP ascent staged and verified, and the site left on current PHP with a compatibility note on anything worth watching. Faster and safer at the end than before the host flipped the switch — which is the point of the whole exercise.
Related symptoms & help
Errors travel in packs. If this one visited, check its friends.
Current PHP, zero wreckage. Staged and verified.
Send the symptom, get a same-day look and a flat quote from the developer who's fixed this exact thing more times than either of us can count.