Upgrading to PHP 8.4 in cPanel: What Breaks & How to Prep

PHP 8.4 has been out for a while now, and hosts are starting to add it to MultiPHP Manager alongside 8.1, 8.2, and 8.3. If you've already dealt with the wall of deprecation warnings that PHP 8.3 threw at older WordPress plugins, you might assume 8.4 is more of the same — bump the version, clean up a few notices, done. It isn't quite that simple. PHP 8.4 changes a few things that specifically trip up code written the "old" way, and if you jump straight from 8.1 or 8.2 to 8.4, you'll hit both generations of warnings at once. Here's what actually changes, why it breaks things, and how to move up without a surprise outage.

Symptom: Deprecation Notices, Fatal Errors, or a Blank Admin After Switching to 8.4

Depending on what your theme and plugins are doing, switching to PHP 8.4 in cPanel's MultiPHP Manager shows up as one of a few things:

• The site loads, but the top of every page (or your error_log) fills with Deprecated: Implicit nullable parameter declaration is deprecated.
• A plugin that worked fine on 8.2 now throws a fatal TypeError: Argument #1 must be of type string, null given.
• wp-admin loads with a broken layout or a blank white screen because a bundled library (a lot of older Composer packages fall into this) hard-crashes on the new version.
• Nothing visibly breaks, but your log volume triples overnight, which matters if you're on a plan with an inode or disk quota limit.

Cause: What PHP 8.4 Actually Changed

The two changes that cause almost all of the real-world breakage are these:

1. Implicitly nullable parameters are deprecated

Older PHP allowed this kind of function signature:

function set_discount(int $percent = null) { ... }

Even though the type is declared as int, giving it a default of null silently made it nullable. PHP 8.4 deprecates that shortcut. The type now has to be explicit:

function set_discount(?int $percent = null) { ... }

This pattern is everywhere in older plugins, page builders, and especially in third-party libraries that haven't been touched since PHP 7. Every one of those functions now logs a deprecation notice the first time it's called with a null default.

2. Stricter type-juggling on internal PHP functions continues to tighten

This trend started back in PHP 8.1 (passing null to a non-nullable internal function argument became deprecated) and PHP 8.4 keeps building on it. Code that does strtolower($maybe_null_value) without a null check — which is extremely common in older WordPress plugins that assumed PHP would just coerce null to an empty string — now logs a notice on 8.4 in more places than it did on 8.1 or 8.2.

Neither of these is fatal by itself — WordPress runs on PHP 8.4 fine at the core level, and most actively maintained plugins already handle it. The pain comes from abandoned or rarely-updated plugins, custom "quick fix" snippets a developer added years ago, and premium themes that stopped receiving updates after the license expired.

Fix: How to Move to PHP 8.4 Without an Outage

Don't do this on production first. Here's the order that actually works:

1. Clone to staging. In cPanel, use Softaculous' clone feature or JetBackup to spin up a staging copy on a subdomain. If you don't have a staging tool, a manual copy of files plus a database export via phpMyAdmin works just as well.
2. Switch only the staging copy's PHP version. WHM/cPanel » MultiPHP Manager lets you set PHP per domain, so your live site keeps running on the current version while staging runs 8.4.
3. Turn on logging, not display. In the MultiPHP INI Editor, set display_errors = Off and log_errors = On on staging so you can read the error_log without exposing warnings to visitors.
4. Install the "PHP Compatibility Checker" plugin (or run wp plugin list --update=available via WP-CLI if you have SSH access) to get a quick read on which installed plugins are flagged as untested above your target PHP version.
5. Click through the site. Load the homepage, a few posts, the checkout flow if it's WooCommerce, and wp-admin's main screens. Then check the error log for anything beyond harmless Deprecated notices — specifically watch for Fatal error or TypeError.
6. Update or replace anything that throws a fatal. Usually a plugin update fixes it. If the plugin is abandoned, look for an actively maintained alternative rather than patching the old plugin's code directly — a WordPress core or plugin update will just overwrite your patch later.
7. Cut production over during low-traffic hours. Once staging survives a real click-through with no fatals, flip the live domain's PHP version in MultiPHP Manager and watch the error log for the next hour.

If your host, including SkyServer, doesn't show 8.4 in MultiPHP Manager yet, that's normal — new PHP versions roll out to shared hosting a few weeks to a couple of months after the official release while the CloudLinux/EasyApache build gets tested. Open a support ticket and ask for a timeline rather than waiting silently.

Prevention: Stop This From Being a Fire Drill Next Time

• Keep plugins and themes current. Most compatibility notices exist because something hasn't been updated in years, not because WordPress itself is fragile.
• Prune what you don't use. Every inactive plugin is still a plugin that can break on the next PHP release. Delete, don't just deactivate.
• Test new PHP versions on staging as soon as they appear in MultiPHP Manager, even if you're not planning to switch immediately. Finding a broken plugin three months early beats finding it the day your host deprecates your current PHP version.
• Set a calendar reminder for PHP end-of-life dates. Each PHP version gets roughly two years of active support and one more year of security-only fixes. Waiting until the last month to upgrade means doing this exercise under time pressure.

Frequently Asked Questions

Will PHP 8.4 break my WordPress site immediately?

Not usually. WordPress core has supported 8.4 since the 6.7 release. Breakage almost always comes from individual plugins or themes, not WordPress itself, so the impact depends entirely on what you have installed.

How do I tell which plugin is causing the deprecation notices?

Check the file path in the error log line — PHP includes the exact plugin folder and file that triggered the notice. If the log is too noisy to read, temporarily deactivate plugins in batches of five and reload the page until the notices stop.

Can I test PHP 8.4 without touching my live site?

Yes — clone the site to a staging subdomain and set the PHP version for that subdomain only in MultiPHP Manager. Your production domain keeps running on its current PHP version the entire time.

Is it safe to just hide the deprecation warnings instead of fixing them?

You can suppress display with display_errors = Off, and that's fine for production either way. But suppressing them doesn't mean the underlying code is safe — some of these deprecations become fatal errors in the next major PHP version, so it's worth tracking down the source rather than only hiding the symptom.

What if an old plugin never gets updated for PHP 8.4?

Stay on your current PHP version until you've replaced it. Don't upgrade PHP and leave a fatal error unresolved just to "get it over with" — a broken checkout or admin panel costs more than waiting a few extra weeks for a proper replacement plugin.