PHP 8.4 in cPanel: Fix Deprecation Warnings Before You Upgrade

If you've moved a site to PHP 8.4 in cPanel and your error log suddenly looks like it's on fire, you're not imagining it. Nothing is actually broken yet — but PHP 8.4 is more vocal about code it doesn't like, and the notices pile up fast. Here's what's normal, what needs fixing before it becomes a real outage, and how to get through the upgrade without a 2 a.m. panic.

Symptom: pages still load, but the log is full of warnings

This is the pattern we see most often after a switch to 8.4 in MultiPHP Manager:

• The site front-end looks fine — no white screen, no 500 error.
• error_log in the site's home directory grows by megabytes within hours.
• Entries start with PHP Deprecated: rather than PHP Fatal error:.
• WordPress admin shows a yellow "Site Health" notice about outdated plugins, or nothing at all if WP_DEBUG is off.
• Shared hosting: you get an email from Getwebup support flagging unusually high error-log disk usage on your account.

That last one catches people off guard. A deprecation notice by itself won't take your site down, but a few hundred thousand of them writing to disk every day absolutely can trip a disk-quota or inode warning.

Why 8.4 is noisier than 8.1 or 8.2

Every major PHP release retires a batch of old behaviour, and 8.4 continues that pattern on top of what 8.1 and 8.2 already flagged. The two changes that generate the most noise on real WordPress and Laravel sites are:

None of these are new problems — they're old code finally getting called out. PHP 8.1 and 8.2 already warned about most of it; 8.4 just makes it impossible to ignore because the volume of notices is so much higher across a typical plugin stack.

The fix, step by step

Step 1: Don't do this on the live site first

If you have a staging copy (cPanel's WordPress Toolkit or a manual clone to a subdomain both work), switch that to PHP 8.4 first. Ten minutes of testing on staging saves a support ticket on production.

Step 2: Run a compatibility pass before you flip the switch

For WordPress, install the free PHP Compatibility Checker plugin, or run it via WP-CLI if you have SSH/Terminal access in cPanel:

wp plugin install php-compatibility-checker --activate
wp php-compat check 8.4

It scans every active plugin and theme against the target PHP version and gives you a list of files that will complain — before you switch anything.

Step 3: Switch the version in MultiPHP Manager

In cPanel: Software → MultiPHP Manager, select the domain, and choose PHP 8.4 from the dropdown. If PHP-FPM is enabled for the account, do the same in MultiPHP INI Editor afterward to confirm error_reporting and display_errors are set the way you expect — a version switch sometimes resets these to the account default.

Step 4: Triage what's actually in the log

Not every deprecation notice needs an immediate fix. Sort them into three buckets:

1. Core WordPress or a maintained plugin — update it. Most active plugin authors patched for 8.4 compatibility months before it went mainstream on hosting platforms.
2. An abandoned plugin with no updates in 2+ years — this is your actual risk. Deprecated today usually means removed in the next major PHP version, and an abandoned plugin will never get fixed. Budget time to replace it now rather than during a forced migration later.
3. Custom code in a child theme or must-use plugin — usually a quick fix. Add the missing ? before a type hint, or declare the property the class is trying to set dynamically.

Step 5: Stop the notices from filling your disk without hiding them

Deprecation notices are useful — you want them logged so you know what still needs fixing. What you don't want is display_errors printing them to the front end, or the log growing unbounded. In wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

This keeps a record in wp-content/debug.log for you to work through, without exposing warnings to visitors or search engines crawling your pages. On the server side, set a log rotation so old entries don't sit around consuming quota — cPanel's own error_log for the domain can be trimmed from File Manager or via a small cron job:

0 3 * * 0 find /home/username/public_html -name "error_log" -size +50M -exec truncate -s 0 {} \;

Prevention: make the next PHP jump boring

• Remove plugins you're not actually using. Every inactive-but-installed plugin is still a file that can trip a compatibility scan and confuse triage later.
• Keep a staging subdomain permanently available so a version bump is a five-minute test, not a project.
• Set a calendar reminder to run the compatibility checker every time cPanel adds a new PHP version to MultiPHP Manager — don't wait for the old version to hit end-of-life.
• For anything custom in functions.php or a must-use plugin, avoid implicit nullable types going forward: write ?array $x = null, not array $x = null.

Deprecation notices are PHP giving you a heads-up, not an emergency. Treat a version bump as a scheduled maintenance task with a staging step, and PHP 8.4 becomes routine instead of a fire drill.