Deprecation notice vs fatal error: which PHP warnings actually matter

The four kinds of PHP messages

Every PHP message starts with its kind. Only the first one stops the page:

These are php.net’s own descriptions of the four levels (php.net):

• Fatal errors: “Fatal run-time errors. These indicate errors that can not be recovered from, such as a memory allocation problem. Execution of the script is halted.”
• Warnings: “Run-time warnings (non-fatal errors). Execution of the script is not halted.”
• Notices: “Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script.”
• Deprecation notices: “Enable this to receive warnings about code that will not work in future versions.”

The difference shows in real output. Both scripts below print “Page starts” and “Page ends” around one line of old plugin code. With a deprecation notice the page is finished; with a fatal error, “Page ends” never comes:

<?php
class Cart_Total {
    public function __construct() {
        $this->total = 42;
    }
}

echo "Page starts\n";
$cart = new Cart_Total();
echo "Total: ", $cart->total, "\n";
echo "Page ends\n";

Page starts

Deprecated: Creation of dynamic property Cart_Total::$total is deprecated in /var/www/html/wp-content/plugins/shop-cart/includes/class-cart-total.php on line 4
Total: 42
Page ends

<?php
echo "Page starts\n";
$by_price = create_function('$a, $b', 'return $a - $b;');
echo "Page ends\n";

Page starts

Fatal error: Uncaught Error: Call to undefined function create_function() in /var/www/html/wp-content/plugins/shop-cart/includes/sorting.php:3
Stack trace:
#0 {main}
  thrown in /var/www/html/wp-content/plugins/shop-cart/includes/sorting.php on line 3

A check that reads the code before an upgrade tells the two apart the same way:

Where the messages show up in WordPress

wp-config.php decides what WordPress does with PHP messages:

• WP_DEBUG off, the normal setting for a live site: WordPress asks PHP to report fatal errors and warnings, but not notices or deprecation notices (WordPress 7.1.2 source). Whether a warning then appears on the page depends on your server’s display_errors setting.
• WP_DEBUG on: every message is reported. It appears on the page unless WP_DEBUG_DISPLAY is false, and it is also written to a log file when WP_DEBUG_LOG is set (developer.wordpress.org).

WordPress switches displaying off by itself during its AJAX, REST API and XML-RPC requests (WordPress 7.1.2 source), so messages from those only reach the log. Normal pages and form submissions don’t get that protection.

How to hide deprecated warnings from visitors

First, is your site actually broken? If it shows WordPress’s critical-error message or a blank page, or something stops working (a form, the checkout, the admin area), there is a fatal error. Hiding messages won’t bring anything back, and it hides the one clue you have. Go to “There has been a critical error” after a PHP update instead.

If the site works and visitors see lines starting with “Deprecated:”, “Notice:” or “Warning:”, the site is set to display PHP messages. That should never be the case on a live site. php.net says of displaying errors: “This is a feature to support your development and should never be used on production systems (e.g. systems connected to the internet).” (php.net) The WordPress documentation agrees: “It is not recommended to use WP_DEBUG or the other debug tools on live sites; they are meant for local testing and staging installs.” (developer.wordpress.org)

These are the logging lines from the WordPress documentation, with the log file moved out of the public web folder, which the documentation allows. Ask your host for the right folder, and remove the lines when you’re done. We tested them on WordPress 7.1.2 with PHP 8.5: the pages stayed clean and the notices went to the log file.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/your-account/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Don’t switch error reporting off completely (for example with error_reporting( 0 );). It hides fatal errors from the log too, and the day something breaks you have no message to go on.

Hiding doesn’t fix anything

A hidden notice is still there: the plugin keeps doing the deprecated thing, and a later PHP version can turn it into an error. For dynamic properties, deprecated since PHP 8.2, the accepted plan is exactly that for PHP 9.0. And create_function() shows how it ends: deprecated in PHP 7.2, removed in PHP 8.0, where every call became a fatal error.

Deprecation notices announce what future PHP versions are expected to change. Fix them in the normal update cycle, before the PHP upgrade that needs them, not in a hurry after it.

Why messages on the page can break a working site

Before a page, PHP sends headers: instructions for the browser, such as “go to the thank-you page”. Once any text has been printed, including a PHP message, headers can no longer be sent. This contact form plugin works on PHP 8.1. On PHP 8.5 its deprecation notice is printed first, so the redirect fails and the visitor sees the messages instead of the thank-you page:

<?php
class Contact_Form {
    public function __construct() {
        $this->sent = true;
    }
}

$form = new Contact_Form();
// After sending, the plugin sends the visitor to a thank-you page
// (WordPress's wp_redirect() does this with the same header):
header('Location: /thank-you/');
echo "Form sent\n";

Form sent

Deprecated: Creation of dynamic property Contact_Form::$sent is deprecated in /var/www/html/wp-content/plugins/contact-box/contact-box.php on line 4

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/wp-content/plugins/contact-box/contact-box.php:4) in /var/www/html/wp-content/plugins/contact-box/contact-box.php on line 11
Form sent

Nothing in the plugin changed except the PHP version. We saw the same in WordPress 7.1.2 on PHP 8.5, with a test plugin that creates a dynamic property and then calls wp_redirect(): with messages displayed, there was no redirect (HTTP 200, two “headers already sent” warnings); with messages logged instead, the redirect worked.

Find the source

A check that reads code finds deprecated and removed features before you upgrade. It can’t see messages that depend on the values a plugin works with while it runs, so keep the log on for a few days after switching.