PHP Error Reporting and Displaying Errors in the Browser

PHP has separate controls for which errors are reported and where they are sent. error_reporting() selects error levels, while display_errors determines whether reported errors are printed in the HTTP response. Errors can still be logged when browser display is disabled. You will also learn why a redirect can make an error message appear to vanish and how to initialize variables so ordinary requests do not create warnings.

PHP error handling has two related but separate configuration decisions:

• error_reporting: Which categories of PHP errors PHP should report.
• display_errors: Whether PHP should add reported errors to the response sent to the browser.
• log_errors: Whether PHP should write reported errors to a server log.

For local development, a common setup is:

error_reporting(E_ALL);
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');

For production, displaying errors is unsafe because messages can reveal file paths, database details, configuration, or application logic. Production applications normally log errors but show a safe, generic error page.

In the provided code, error_reporting(E_ALL) enables reporting, but it does not force browser display. If display_errors is disabled for the PHP web-server environment, the warning goes only to the log.

There is also a control-flow issue: after a PDO exception is caught and echoed, the script still runs:

header('Location: ' . $_SERVER[]);
;

Think of PHP errors as alerts from a building alarm system:

• error_reporting decides which sensors are active.
• display_errors decides whether the alert appears on the public display screen (the browser).
• log_errors decides whether the alert is written in the security logbook (the server log).

An alert can be recorded in the logbook without being shown publicly.

A redirect is like immediately sending the visitor to a different room. Even if an alert briefly appeared in the first room, the visitor ends up looking at the second room instead.

Enable detailed errors temporarily during local development:

<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');

Place this at the beginning of the executed PHP file, before output. This is useful for runtime errors in that file.

For errors that happen before the script can run, such as PHP startup or syntax errors, configure the web-server PHP configuration instead:

display_errors = On
display_startup_errors = On
error_reporting = E_ALL
log_errors = On

The option name is exactly display_errors. A misspelling such as display_erros is ignored because it is not a valid PHP directive.

Initialize variables before branches that use them:

<?php
$err = [];
$form = [
    'display_name' => '',
    'email' => '',
    'password' => ,
];

 ([] === ) {
     (([] ?? )) {
        [] = ;
    }
}

 (  ) {
      . (, ENT_QUOTES, ) . ;
}

Consider this small example:

<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');

$errors = [];

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $email = trim($_POST['email'] ?? '');

    if ($email === '') {
        $errors[] = 'Email is required.';
    }
}

foreach ($errors as $error) {
    echo $error . PHP_EOL;
}

On an initial page visit:

1. PHP enables reporting and browser display for this request.
2. $errors becomes an empty array.
3. The request method is usually GET, so the POST block is skipped.
4. foreach runs over an empty array.
5. Nothing is printed, and no warning occurs.

When the form is submitted with an empty email:

• Local debugging: Show warnings, notices, and stack traces while building a feature on a local machine.
• Production monitoring: Keep display_errors disabled but use logs to investigate failures without exposing internal details to visitors.
• Form validation: Create an errors array before validating fields so every request can safely render error messages.
• Database operations: Catch database exceptions, log technical details, and show users a general failure message.
• API development: Return controlled JSON error responses rather than raw PHP warnings that would break the API response format.
• Deployment troubleshooting: Compare the PHP configuration used by the web server with the configuration used by the command line.

Real projects usually separate developer diagnostics from user-facing responses.

Validate first, then perform database work

$errors = [];

$email = trim($_POST['email'] ?? '');
if ($email === '') {
    $errors[] = 'Email is required.';
}

if ($errors !== []) {
    // Render the form again with errors.
    return;
}

// Only attempt the database operation after validation succeeds.

Catch, log, and return a safe message

try {
    $statement = $pdo->prepare(
        'INSERT INTO users (display_name, email) VALUES (:display_name, :email)'
    );

    $statement->execute([
        ':display_name' => $displayName,
        ':email' => $email,
    ]);
} catch (PDOException $exception) {
    error_log($exception->getMessage());
    [] = ;
}

Confusing reporting with display

This reports all error levels but does not guarantee browser output:

error_reporting(E_ALL);

For local development, also enable display:

ini_set('display_errors', '1');

Misspelling display_errors

This setting is invalid because its name is misspelled:

display_erros = On

Use:

display_errors = On

Editing the wrong php.ini

PHP running through Apache, PHP-FPM, and the command line can load different configuration files. php --ini describes the CLI configuration; it may not be the configuration used for a browser request.

Create a temporary diagnostic file in a safe local environment:

<?php phpinfo();

Check and the effective values for and . Remove the file afterward, especially on public servers.

// Local development only: place near the start of the entry script.
error_reporting(E_ALL);
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');

; php.ini development settings
display_errors = On
display_startup_errors = On
error_reporting = E_ALL
log_errors = On

• error_reporting = which errors PHP reports.
• display_errors = whether browser output includes errors.
• log_errors = whether errors go to logs.
• The valid directive is display_errors, with two r characters in errors.
• Initialize arrays before conditionals if they are used later: $errors = [];.
• Use $_POST['field'] ?? '' when a submitted field may be absent.
• Redirect only after a successful action when the current response does not need to display errors.

Why does PHP show errors in the log but not in my browser?

Usually log_errors is enabled while display_errors is disabled. PHP is reporting the problem, but it is configured to send it only to the server log.

Is error_reporting(E_ALL) enough to display PHP errors?

No. It chooses which error levels are reported. display_errors must also be enabled for reported errors to be included in the browser response.

Why does display_errors = On in php.ini not work?

Confirm that the directive is spelled correctly and that you edited the configuration file loaded by Apache or PHP-FPM, not only the CLI PHP configuration. Use phpinfo() temporarily to check the loaded file and effective values.

Should I use E_ALL | E_STRICT?

Usually no. In modern PHP, use E_ALL. Adding E_STRICT is redundant in supported modern versions.

Why is $err undefined on the first page visit?

It is assigned only inside the POST branch, but foreach ($err as ...) runs for both GET and requests. Initialize it before the condition with .

• PHP configuration (php.ini) — Determines default PHP behavior for a specific server environment.
• PHP error levels — Explains warnings, notices, deprecations, fatal errors, and what E_ALL selects.
• Exception handling with try and catch — Handles recoverable failures such as PDO database exceptions.
• PDO prepared statements — Provides safe parameterized SQL queries and configurable error modes.
• Form validation — Uses an errors array to collect and display problems in submitted user input.
• Null coalescing operator (??) — Safely handles missing request fields without undefined-key warnings.
• Post/Redirect/Get pattern — Prevents duplicate submissions but must be used only after the appropriate response is complete.
• Server logging — Records technical failures securely for debugging and monitoring.