How to Set Up PHP Error Reporting for Development and Production

Proper error handling is the backbone of any robust PHP application. During development you want every warning, notice, and error to be displayed on screen so you can fix problems quickly. In production, however, exposing internal errors to users can be a security risk and ruin the user experience. This guide walks you through configuring PHP error reporting for both environments, using php.ini, .htaccess, and runtime ini_set() methods.

Why Error Reporting Matters

Understanding the difference between development and production error reporting helps you:

• Detect bugs early with detailed messages.
• Prevent sensitive data leakage in live sites.
• Maintain clean logs for post‑mortem analysis.
• Improve overall application performance by disabling unnecessary output.

Core PHP Settings for Error Reporting

PHP controls error handling through a handful of directives. The most important ones are:

error_reporting

Defines which PHP error levels are reported. Use the predefined constants or bitwise combinations, e.g., E_ALL for all errors.

display_errors

When set to On, errors are printed to the browser. This should be enabled only in development.

log_errors

When On, errors are written to the server’s error log or a custom file. This is essential for production.

error_log

Specifies the path to the custom log file. Keeping logs separate from the web root adds a layer of security.

Setting Up PHP Error Reporting for Development

In a development environment you typically want maximum visibility. Follow these steps:

1. Edit php.ini

; Development settings
error_reporting = E_ALL
display_errors = On
display_startup_errors = On
log_errors = On
error_log = /path/to/your/project/logs/php-error.log
    

2. Use .htaccess (if you cannot modify php.ini)

php_value error_reporting 32767   ; Equivalent to E_ALL
php_flag display_errors On
php_flag display_startup_errors On
php_flag log_errors On
php_value error_log /full/path/to/logs/php-error.log
    

3. Runtime configuration (optional)

Place these lines at the top of your entry script (e.g., index.php) for quick toggling:

ini_set('error_reporting', E_ALL);
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
ini_set('log_errors', '1');
ini_set('error_log', __DIR__ . '/logs/php-error.log');
    

4. Verify the configuration

Create a test file error_test.php with the following code to ensure errors are displayed:

Open the file in the browser; you should see both the warning and the fatal error output.

Setting Up PHP Error Reporting for Production

Production settings prioritize security and performance. The goal is to log errors silently while showing generic messages to users.

1. Edit php.ini for production

; Production settings
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
display_startup_errors = Off
log_errors = On
log_errors_max_len = 1024
error_log = /var/log/php-errors.log
    

2. .htaccess override (if needed)

php_value error_reporting 30719   ; E_ALL & ~E_DEPRECATED & ~E_STRICT
php_flag display_errors Off
php_flag display_startup_errors Off
php_flag log_errors On
php_value error_log /var/log/php-errors.log
    

3. Runtime guard (recommended)

Place a safety net at the very start of your application to enforce production settings regardless of server configuration:

if (isset($_SERVER['APP_ENV']) && $_SERVER['APP_ENV'] === 'production') {
    ini_set('display_errors', '0');
    ini_set('display_startup_errors', '0');
    ini_set('log_errors', '1');
    ini_set('error_log', '/var/log/php-errors.log');
    error_reporting(E_ALL & ~E_DEPRECATED & ~E_STRICT);
}
    

4. Custom error handler (optional)

Implement a custom handler to transform PHP errors into exceptions or to send alerts:

set_error_handler(function ($severity, $message, $file, $line) {
    // Convert to ErrorException
    if (error_reporting() & $severity) {
        throw new ErrorException($message, 0, $severity, $file, $line);
    }
});
    

Best Practices & Common Pitfalls

Never commit production php.ini settings to a public repo

Separate configuration files for each environment (e.g., .env.production, .env.development) keep sensitive paths out of source control.

Rotate and protect log files

Use logrotate or a similar tool to prevent logs from consuming disk space, and set proper file permissions (e.g., 640 owned by the web server user).

Avoid “@” error suppression operator

Suppressing errors hides problems that should be logged. Use proper checks (e.g., file_exists()) instead.

Test both environments before deployment

Automated CI pipelines should run a sanity test that confirms display_errors is off in the production build.

Testing Your Configuration

After setting up, run these quick checks:

1. Development: Access a page that triggers a notice. You should see the notice on the screen and a matching entry in the log file.
2. Production: Trigger the same notice. The screen should display a generic “Internal Server Error” (or a custom error page), while the log file contains the full error details.

Conclusion

Balancing visibility and security is key when configuring PHP error reporting. By following the steps above—using php.ini for global defaults, .htaccess or ini_set() for overrides, and a reliable logging strategy—you can ensure that developers get the information they need while end‑users see a clean, safe interface.

Remember to revisit these settings whenever you upgrade PHP or change your server architecture. Proper error reporting not only speeds up debugging but also protects your application from unintended data exposure.