Insights

It's one of those Monday morning surprises nobody wants. The site was fine Friday. Nobody touched anything over the weekend. Then someone tries to load a page and gets a white screen, a stack of PHP errors, or a 500 that tells you absolutely nothing useful.

More often than not, when we get this call, the culprit is a PHP version change on the server — one the shared hosting provider made without much warning, often buried in a maintenance email nobody read.

It's not unique to ExpressionEngine, and it doesn't happen every day — but when it does, it tends to catch people off guard. It happened with the PHP 5 to 7 transition. It happened again with PHP 7.4 going end-of-life. And as hosts push sites from PHP 8.1 to 8.2 or 8.3, it comes up again. The pattern is the same every time, and so is the fix path — once you know what you're looking at.

Why Shared Hosting Providers Do This Without Asking

Shared hosting companies manage thousands of servers. When a PHP version reaches its official end of life, it stops receiving security patches. They have a legitimate reason to move people off of it — an unpatched PHP version on a shared server is a risk to every account on that machine, not just yours.

Most send an email. Some just flip the switch. Either way, your site is now running on a PHP version it was never tested against, and anything that wasn't built for that version becomes a potential failure point.

ExpressionEngine core has generally kept pace — EE7 runs cleanly on PHP 8.1, 8.2, and 8.3. The trouble is almost never EE itself. It's everything around it.

What Actually Breaks

The first thing to check is third-party add-ons. This is where we spend the most time when we're diagnosing a post-upgrade site. Add-ons built for PHP 7.x will often throw deprecation notices or outright fatal errors on PHP 8.x — things like deprecated function calls, removed interfaces, or changed behavior around how PHP handles certain data types.

Some specific things we've seen break repeatedly:

• Add-ons using the Serializable interface — PHP 8.1 deprecated how this interface works. Any add-on that implements it the old way will throw errors immediately.
• String-to-integer implicit conversions — PHP 8 made these stricter. Add-ons that relied on PHP silently handling type coercion will fail where they used to pass.
• Functions removed between PHP versions — each() was removed in PHP 8.0. create_function() too. Old add-ons occasionally still call these.
• Custom modules built in-house years ago — These are the worst, because there's often no vendor to contact for an update. Someone has to go in and fix the code.

The second place to look is your PHP configuration itself. Hosts don't always carry over custom php.ini settings when they upgrade. Extensions that were enabled, memory limits, file upload sizes — any of these could be different on the new version.

The error message on screen is almost never the real error. PHP will often display a generic 500 or a blank page when the actual problem is a fatal error being suppressed. Your first job is always to find the real error log.

How to Actually Diagnose It

Turn on PHP error display, or better, pull your server's PHP error log. On most hosts this lives in your account's logs directory or is accessible through cPanel. You want to see the actual error — the file, the line number, and the message. That's your starting point.

Once you have a real error, you can usually trace it to a specific add-on or file in seconds. Search for that add-on's name and "PHP 8 compatibility" and you'll often find the developer has already released a patch — or a forum thread explaining they haven't.

If errors are suppressed and you're not getting useful output anywhere, enable EE's debug mode temporarily (set $debug = 1 in your config.php) to surface what EE itself is catching. Just don't leave debug mode on in production.

One thing we do on any server-level change: check phpinfo() output on the new version against what you remember from the old one. Look at loaded extensions, key settings like max_execution_time and upload_max_filesize, and whether anything critical is now missing. Hosts sometimes quietly drop extensions during PHP upgrades.

Your Options Once You Know What's Broken

If a third-party add-on is the culprit, you have a few paths:

The add-on has a PHP 8-compatible update — straightforward, install it. Most actively maintained add-ons from developers like BoldMinded, Croxton, or Hop Studios have kept pace. Check the add-on's changelog before assuming it's broken.

The add-on is abandoned or hasn't been updated — harder conversation. You can either find a replacement that does the same job, have someone patch the add-on directly (usually a small fix), or ask your host to temporarily hold you at the old PHP version while you sort it out. The last option buys time but isn't a solution.

If it's custom code that was built in-house and nobody's touched it in five years, that's a code review project. Depending on what it does, it could be an afternoon or it could be a week. We've seen both.

The EE6 Factor

If you're still on ExpressionEngine 6, the PHP version pressure compounds the version pressure you're already under. EE6 enters full retirement at the end of 2026 — no more security patches, no bug fixes. We wrote more about what that timeline means in this piece on the EE6 upgrade game plan.

The short version: a host PHP upgrade that breaks your EE6 site isn't necessarily a reason to panic, but it is a good forcing function to think about whether patching the add-on for PHP 8 compatibility is the right investment, or whether that energy should go toward an EE7 upgrade instead. Sometimes fixing the symptom makes sense. Sometimes you're just delaying the inevitable.

EE7 on PHP 8.3 is a stable, well-supported combination. If you're going to spend time and money on your site this year anyway, it's worth at least running the numbers on doing the upgrade properly rather than patching your way forward.

Going Forward: How to Avoid Being Caught Off Guard

A few things that help us stay ahead of this for client sites:

• Know what PHP version you're on — log into cPanel or your hosting dashboard and check. phpinfo() works too. You should know this the same way you know what version of EE you're running.
• Watch the PHP EOL calendar — php.net publishes end-of-life dates for every active version. When a version is approaching EOL, your host will eventually act on it, whether they tell you in advance or not.
• Test upgrades in a staging environment — before your host does it for you, change the PHP version yourself in a dev or staging copy of the site and see what breaks. This is the only way to control the timing.
• Keep a list of your add-ons — sounds basic, but we've worked on sites where nobody knew what was installed or where it came from. When something breaks, that list is the first thing you need.

None of this is complicated, but it requires someone to actually own it. That's usually the gap — not a lack of knowledge, but a lack of accountability for the site's technical health. It's also worth noting that not all shared hosting is the same. Some providers give you much more control over your PHP version and much more notice before making changes. If you're tired of your host pulling the rug, we offer managed hosting for ExpressionEngine sites where that kind of thing doesn't happen without a conversation first.

If your ExpressionEngine site just went sideways after a server change, or if you want to get ahead of PHP version changes before they catch you, reach out to us. We do this kind of diagnostic and upgrade work regularly and can usually tell you what you're dealing with pretty quickly.