How to fix common PHP 8.4 deprecation notices in WordPress

First: is it really a deprecation notice?

Look at the first word of the message:

• “Deprecated:” The page works. Everything on this page applies.
• “Fatal error:” The page stops. On PHP 8.4 that’s usually one of five removed MySQLi constants or a missing extension such as IMAP; start with the critical error guide.

For the difference in general: deprecation notice or fatal error.

Step 1: keep them off your pages

Notices printed on a page look broken to visitors, and they can break redirects and logins (why). WordPress already leaves them out while WP_DEBUG is off: it reports errors and warnings, not deprecation notices (WordPress 7.1.2 source). If you see them anyway, either WP_DEBUG is on, or your host displays every PHP message.

To fix them, you want them in a log, not on the page: the WordPress debug log has the three lines for wp-config.php. Do it on a staging copy if you can.

Step 2: group them by plugin or theme

Every notice ends with a path such as wp-content/plugins/order-notes/order-notes.php. The folder after plugins/ or themes/ is the one responsible. Sort your log by that folder: a long log may come from only one or two plugins.

A check that reads code gives you the same list without waiting for visits. CompatNav, a free plugin on wordpress.org, lists the PHP 8.4 deprecation notices per plugin and theme, with file and line, on your own server:

Step 3: update

Dashboard → Updates. Maintained plugins and themes fix these notices over time, so an update may clear a whole group at once. Check the log again afterwards.

Step 4: send the rest to the developers

For each remaining group, send the developer one full line of the notice: the message, the file and the line. Contacting the author has a message you can adapt. Don’t edit a plugin’s files yourself: the next update overwrites them.

For developers: the fix for each notice

The PHP 8.4 notices you’re most likely to meet, as PHP writes them, with the change that removes each. Each fix is tested on the official PHP builds, with full examples in WordPress and PHP 8.4:

The most common one, side by side. A parameter made nullable only by its = null default gets a notice on PHP 8.4:

<?php
class Order_Note {
    public function __construct(string $text, DateTime $created = null) {
        echo $text, $created ? ' (dated)' : ' (no date)', "\n";
    }
}

new Order_Note('Gift wrap');

Gift wrap (no date)

Deprecated: Order_Note::__construct(): Implicitly marking parameter $created as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/wp-content/plugins/order-notes/order-notes.php on line 3
Gift wrap (no date)

The explicit ? removes it, and works on PHP 7.1 and later:

<?php
class Order_Note {
    public function __construct(string $text, ?DateTime $created = null) {
        echo $text, $created ? ' (dated)' : ' (no date)', "\n";
    }
}

new Order_Note('Gift wrap');

Gift wrap (no date)

Gift wrap (no date)

Gift wrap (no date)

Before the next upgrade

Deprecation notices are PHP announcing what it plans to change. Checking for the next version before you switch shows them while there’s time: preparing for PHP 8.4 has the full checklist, and the PHP 8.4 compatibility checker what a check covers.