PHP warning: what it means and how to fix it

A PHP warning means something went wrong during execution, but not badly enough to stop the script. Unlike a fatal error, which kills the script immediately, a warning lets PHP continue running. The page may still load, the form may still submit, the plugin may still function – but something happened that was not supposed to, and ignoring it usually leads to worse problems later.

Warnings are PHP telling you that your code did something questionable: used a variable that does not exist, passed the wrong type of argument to a function, tried to include a file that is missing, or divided a number by zero. In a WordPress context, warnings most commonly come from plugins and themes, and they can appear in your error log hundreds of times per hour without you ever noticing – unless you know where to look.

This guide covers the most common PHP warnings, what causes each one, how to fix them properly, and why suppressing warnings with @ or turning off error reporting is almost always the wrong approach.

PHP error levels: where warnings fit#

PHP has a hierarchy of error severity. Understanding where warnings sit in this hierarchy helps you prioritize what to fix.

Fatal errors ( E_ERROR ) stop execution immediately. The script dies, the page does not load, and WordPress may show the white screen of death or a “critical error” message. These demand immediate attention because the site is broken.

Warnings ( E_WARNING ) are the next level down. Something went wrong, but PHP can continue. The script keeps running, which means the page may load with missing content, broken functionality, or incorrect data. Warnings are dangerous precisely because they do not break the page outright – they let broken code run and produce subtly wrong results.

Notices ( E_NOTICE ) are minor issues. Accessing an undefined variable, using undefined constants, or accessing an array offset that does not exist. They usually indicate sloppy code rather than broken logic.

Deprecation notices ( E_DEPRECATED ) flag code that uses features scheduled for removal in a future PHP version. They work today but will break when you upgrade PHP.

On a production WordPress site, warnings and notices are typically hidden from visitors but written to the error log. If you are seeing warnings in the browser, your server has display_errors turned on, which should only be enabled during development. For the full guide on controlling error visibility, see how to display PHP errors and enable error reporting.

How to find PHP warnings#

Warnings are invisible on a properly configured production server. They write to the error log, not the screen. You need to check the log file to find them.

Check the PHP error log

The location depends on your server configuration. Common paths:

/var/log/php/error.log
/var/log/php-fpm/error.log
/var/log/php8.3-fpm.log

To find the configured log file path:

php -i | grep error_log

Or check through a phpinfo() page. For a full walkthrough of finding your php.ini and error log, see how to check your PHP version and find php.ini.

Check the WordPress debug log

WordPress has its own debug logging that captures PHP errors, including warnings. Enable it in wp-config.php :

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

This writes all PHP errors (including warnings and notices) to wp-content/debug.log without displaying them to visitors. The WP_DEBUG_DISPLAY line is important – leaving it out or setting it to true on a production site shows raw PHP errors to visitors, which is a security risk.

Read the log

tail -100 /var/www/html/wp-content/debug.log

Or search for warnings specifically:

grep "Warning:" /var/www/html/wp-content/debug.log | tail -50

A typical warning entry looks like this:

[07-Apr-2026 14:23:15 UTC] PHP Warning: Undefined variable $user_data in /var/www/html/wp-content/plugins/example-plugin/includes/class-user.php on line 47

This tells you the error type (Warning), the message (Undefined variable), the file, and the line number. That is everything you need to find and fix it.

For a complete guide to configuring and managing PHP log files, see PHP error logging: how to log errors to a file.

The most common PHP warnings#

Undefined variable

Warning: Undefined variable $username in /path/to/file.php on line 12

The code uses a variable that was never assigned a value. This happens when a variable is set inside a conditional block but used outside it, when a variable name is misspelled, or when code assumes a variable was set by an earlier function that did not actually set it.

Example:

if ($user_logged_in) {
    $welcome_message = "Hello, $username";
}
echo $welcome_message; // Warning if $user_logged_in is false

Fix: Initialize variables before conditional blocks, or check if they exist before using them:

$welcome_message = '';
if ($user_logged_in) {
    $welcome_message = "Hello, $username";
}
echo $welcome_message;

In WordPress plugins, this warning commonly appears when code reads from $_GET or $_POST without checking if the key exists first. The correct approach is isset() :

$page = isset($_GET['page']) ? $_GET['page'] : '';

Undefined array key

Warning: Undefined array key "email" in /path/to/file.php on line 25

The code accesses an array index that does not exist. This is the array equivalent of undefined variable – the code assumes a key is present, but it is not.

Common cause: Processing form data or API responses without checking which fields were actually submitted.

Fix: Check before accessing:

$email = isset($data['email']) ? $data['email'] : '';
// Or with PHP 7.0+ null coalescing:
$email = $data['email'] ?? '';

include/require failed to open stream

Warning: include(config/settings.php): Failed to open stream: No such file or directory in /path/to/file.php on line 8

PHP tried to include a file that does not exist at the specified path. With include , this is a warning and execution continues. With require , the same situation produces a fatal error and execution stops.

Common causes:

• A plugin or theme references a file that was deleted or moved
• A relative path that works in one context but fails in another
• A missing dependency that was not installed
• File permissions preventing PHP from reading the file – check file ownership and permissions if the file exists but PHP cannot read it

Fix: Verify the file exists at the expected path. If the warning comes from a plugin, the plugin may be partially installed or corrupted. Reinstall it from the WordPress dashboard or via WP-CLI.

Division by zero

Warning: Division by zero in /path/to/file.php on line 15

The code divides a number by zero. In PHP 7, this produces a warning and returns false (for the / operator) or throws a DivisionByZeroError (for the intdiv() function). In PHP 8, the / operator with an integer zero divisor throws a DivisionByZeroError instead of a warning.

Common cause: A calculation that uses a variable from user input or a database query without validating that it is not zero.

Fix: Check before dividing:

$average = ($count > 0) ? $total / $count : 0;

Array to string conversion

Warning: Array to string conversion in /path/to/file.php on line 30

The code tries to use an array in a context that expects a string – echoing it, concatenating it, or passing it to a function that expects a string argument. PHP converts the array to the literal string “Array” and issues a warning.

Common cause: A function returns an array when the code expects a scalar value, or a database query returns an array of rows when the code assumes a single value.

Fix: Access the specific array element you need instead of the entire array:

// Wrong:
echo $result;           // Warning if $result is an array

// Right:
echo $result['name'];   // Access the specific value

Cannot modify header information

Warning: Cannot modify header information - headers already sent by (output started at /path/to/file.php:5) in /path/to/another-file.php on line 20

PHP tried to send an HTTP header (a redirect, a cookie, or a content-type header) after output was already sent to the browser. HTTP headers must come before any output, including whitespace, newlines, or BOM characters.

Common causes:

• A space or newline before the opening  <?php  tag
• A BOM (byte order mark) at the beginning of a PHP file (invisible but present in files saved with certain text editors)
• An  echo  or HTML output before a  header() ,  setcookie() , or  wp_redirect()  call
• A PHP error or warning earlier in execution that produced output

Fix: The error message tells you exactly where the premature output started. Check that file and line for stray whitespace, BOM characters, or early output. In WordPress plugins, ensure no output happens before wp_redirect() calls.

fopen/fwrite permission denied

Warning: fopen(/var/www/html/wp-content/uploads/log.txt): Failed to open stream: Permission denied in /path/to/file.php on line 40

PHP tried to open a file for writing but does not have permission. The web server user ( www-data , nginx , or your account user) does not have write access to the target directory or file.

Fix: Check file ownership and permissions. The directory needs to be writable by the PHP process user. On most WordPress installations, wp-content/uploads should be owned by the web server user with 755 directory permissions and 644 file permissions.

When warnings become errors#

PHP 8 changed how several former warnings behave. Operations that produced warnings in PHP 7 now throw errors or exceptions in PHP 8. This means code that worked (with warnings) on PHP 7 may break completely on PHP 8.

Notable changes:

• Undefined variables: still a warning in PHP 8.0, but promoted to  E_WARNING  from  E_NOTICE
• Division by zero: throws  DivisionByZeroError  for integer division in PHP 8.0
• Passing null to non-nullable internal functions: produces deprecation notices in PHP 8.1, will become errors in PHP 9.0
• String/array offset access on non-arrays: fatal error in PHP 8.0 (was warning in PHP 7)

This is why fixing warnings matters even when the site seems to work fine. A PHP upgrade can turn every warning into a fatal error. If your error log is full of warnings, test thoroughly before upgrading PHP versions and fix the warnings beforehand.

Suppressing warnings vs fixing them#

PHP provides the @ operator to suppress individual errors:

$result = @file_get_contents($url);

This silences any warning that file_get_contents produces. The problem is that it also hides the information you need to diagnose failures. If the URL is unreachable, the function returns false with no logged warning, and you have no idea why.

There are rare cases where suppression is appropriate – for example, when checking if a file exists using fopen() where the expected behavior includes the file not existing. But as a general practice, suppressing warnings hides bugs.

Similarly, lowering the error_reporting level to exclude warnings:

error_reporting(E_ERROR);

This tells PHP to ignore everything except fatal errors. The warnings are still happening – you just cannot see them. The code is still doing things it should not be doing. And when you eventually upgrade PHP and those warnings become errors, the site breaks with no warning (because you turned warnings off).

The correct approach: fix the code that produces the warning. Every warning has a specific cause and a specific fix. The fixes are usually simple – adding an isset() check, initializing a variable, validating a divisor. The time spent fixing warnings is always less than the time spent debugging the mysterious breakage they cause later.

Warnings from WordPress plugins#

Most PHP warnings on a WordPress site come from plugins, not from WordPress core. Core is thoroughly tested and rarely produces warnings on supported PHP versions. Plugins vary enormously in code quality.

If warnings in your error log point to a plugin file:

1. Update the plugin. The warning may already be fixed in a newer version
2. Check the plugin’s support forum for others reporting the same warning
3. Check PHP compatibility. Some plugins have not been updated for PHP 8.x and produce warnings on newer versions
4. Consider replacing the plugin if it is abandoned (no updates in over a year) with a maintained alternative

If your error log is filling up with hundreds of identical warnings from the same plugin, the log file itself becomes a disk space issue. Monitor log file sizes periodically – a warning firing on every page load can generate gigabytes of log data. For guidance on finding and cleaning large log files, see how to check disk space in Linux.

PHP warnings on Hostney#

On Hostney, PHP error logging is enabled by default on all accounts. Warnings and errors are written to log files accessible through the control panel. display_errors is off in production to protect your site’s security.

PHP settings are managed through Hosting > PHP Manager in the control panel. You can adjust error_reporting levels and other PHP configuration options without editing php.ini directly.

If you need to investigate warnings in detail, enable WordPress debug logging by adding the WP_DEBUG constants to wp-config.php . SSH access is available on all plans through the Terminal Access section in the control panel, so you can read and search log files directly from the command line.