Catching Bugs in Code: How to Enable PHP Error Output (and Not Slow Down Your Site)

Online Python Trainer for Beginners

Learn Python easily without overwhelming theory. Solve practical tasks with automatic checking, get hints in Russian, and write code directly in your browser — no installation required.

Start Course

Introduction: Why Are Developers Afraid of the White Screen?

\n\n

Every PHP developer has encountered this situation at least once: the code seems to be written, but instead of a result — a blank page. No errors, no warnings. Only silence and cold sweat. Sound familiar?

\n\n

On Stack Overflow, the question “How do I get PHP errors to display?” has garnered thousands of views and hundreds of answers. This is no coincidence: the ability to properly enable and handle errors is a fundamental skill that saves hours of debugging. But there is a nuance: incorrect configuration can not only fail to help but also reduce the performance of your site or, worse, expose vulnerabilities.

\n\n

In this article, we will cover all the ways to enable PHP error output — from quick solutions for local development to secure settings for a production server. And, of course, we will talk about optimization: how to avoid flooding logs and slowing down your site.

\n\n

Quick Primer: What Types of PHP Errors Are There?

\n\n

Before enabling display, it's helpful to understand what we are dealing with. PHP generates several error levels:

\n\n
    \n
  • E_ERROR — fatal error. The script stops. Example: out of memory, calling a non-existent class.
  • \n
  • E_WARNING — non-fatal. The script continues, but something went wrong. Example: including a file that doesn't exist.
  • \n
  • E_NOTICE — notice. Usually about minor issues (undefined variable).
  • \n
  • E_PARSE — syntax error. Occurs before code execution; catching it at runtime is difficult.
  • \n
  • E_ALL — includes all levels except E_STRICT (prior to PHP 8.0).
  • \n
\n\n

Remember: during development, we want to see all errors. On a production server — only critical ones, and even then in logs, not on the screen.

\n\n

Method #1: Quick and Dirty — Directly in Code

\n\n

The simplest method for one-time debugging is to insert two magic lines at the beginning of your script:

\n\n
<?php\nini_set('display_errors', 1);\nini_set('display_startup_errors', 1);\nerror_reporting(E_ALL);\n?>
\n\n

What's happening here?

\n
    \n
  • display_errors — enables error output to the screen.
  • \n
  • display_startup_errors — shows errors that occurred during PHP startup (e.g., in php.ini).
  • \n
  • error_reporting(E_ALL) — sets the reporting level: show everything.
  • \n
\n\n

This method is ideal for a single file you are debugging. But there are downsides: you must remember to remove these lines before deploying to production. Otherwise, you risk showing users the "guts" of your application.

\n\n

Method #2: Configuring php.ini — Globally and Forever

\n\n

If you work on a local machine or control the server, it's easier to edit php.ini. Find this file (usually in /etc/php/ or /usr/local/etc/php/) and change the following directives:

\n\n
display_errors = On\ndisplay_startup_errors = On\nerror_reporting = E_ALL
\n\n

After the changes, don't forget to restart the web server:

\n
sudo systemctl restart apache2\n# or\nsudo systemctl restart nginx php8.1-fpm
\n\n

Important: on a production server, display_errors should be Off. Instead, configure error logging to a file:

\n\n
display_errors = Off\nlog_errors = On\nerror_log = /var/log/php_errors.log\nerror_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
\n\n

This reduces output load and protects site data.

\n\n

Method #3: Via .htaccess — For Shared Hosting

\n\n

If you don't have access to php.ini (e.g., cheap hosting), use the .htaccess file in the site root:

\n\n
php_flag display_errors on\nphp_flag display_startup_errors on\nphp_value error_reporting 32767

Blogs

Book Recommendations