How to enable the "display_errors" option to show PHP error messages

When a PHP page shows a blank screen or a bare "500" error, you want to see the real message. PHP's display_errors setting prints errors in the browser, which is handy while you develop, and dangerous on a live site. This guide shows how to see PHP errors safely on Domain India hosting: read the log first, and display errors only briefly, only where visitors can't see them.

1. What display_errors does, and why it stays off in production

display_errors decides whether PHP prints error messages into the page it is building. A displayed error reveals file paths, sometimes database names or query fragments, and which software and version you run. Attackers look for exactly that. It also breaks pages for visitors, and can corrupt JSON responses and redirects.

Two related settings matter:

• log_errors writes errors to a log file instead of the page. This is what you want on a live site.
• error_reporting decides which errors count at all. E_ALL reports everything, which is right while you develop.

Measured on our cPanel and DirectAdmin servers on 23 September 2026: display_errors = Off and log_errors = On by default. So your errors are already being recorded; you only need to find them.

2. First, read the error log

On cPanel, whether a domain uses the error_log next to the script or the file in logs depends on how its PHP runs, so check both. Open them in File Manager; the newest lines are at the bottom. For how to read a log line, see reviewing error logs in cPanel and DirectAdmin.

3. Show errors for one script with ini_set()

For a quick look at one script you are working on, add these lines at the very top of that script:

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

This affects only requests to that script. Two limits:

• A parse error (a missing ; or bracket) in the same file stops PHP before these lines run, so nothing is shown. Check the log instead.
• Remove the lines as soon as you have the message.

To show errors only to you on a live site, wrap them in a check of your own IP address:

<?php
if (($_SERVER['REMOTE_ADDR'] ?? '') === '203.0.113.5') { // your IP
    ini_set('display_errors', '1');
    error_reporting(E_ALL);
}

4. Turn it on for a folder with .user.ini

A .user.ini file applies settings to its folder and every subfolder. It works with the PHP-FPM and CGI handlers our shared servers use. Create it in the folder of your test copy, for example public_html/staging:

display_errors = On
error_reporting = E_ALL

Changes can take up to 5 minutes to apply, because PHP caches these files. Delete the lines, or the file, when you're done.

On cPanel, the MultiPHP INI Editor in the Software section can also change display_errors for a domain, if the editor offers it in Basic Mode. It changes the whole domain, so use it only on a test domain or for a few minutes. On DirectAdmin and Webuzo we don't name a panel screen; use .user.ini or ask support.

Editing the server's php.ini and restarting Apache, as other guides suggest, is not possible on shared hosting and not needed.

5. WordPress: WP_DEBUG without showing errors

WordPress has its own switches in wp-config.php, above the line /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // write to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // never print errors on the page

This records errors without showing them to visitors. Two cautions:

• wp-content/debug.log can be downloaded by anyone who guesses the address. Since WordPress 5.1 you can give WP_DEBUG_LOG a path instead of true, for example a file in your home folder outside public_html.
• Set WP_DEBUG back to false and delete the log when you have finished.

For step-by-step screenshots, see how to enable debugging in WordPress. Frameworks have the same idea: in Laravel, keep APP_DEBUG=false in .env on the live site.

6. When nothing appears

• Blank page, empty logs: you may be looking at a cached copy; add ?t= with a new value. Check both log locations in section 2.
• Settings don't change: allow 5 minutes for .user.ini, and check that you edited the folder the site actually runs from. A setting made for one PHP version doesn't follow you to another; see How to change your PHP version.
• 500 right after an edit: look for a php_value or php_flag line in .htaccess. See Troubleshooting 500 Internal Server Error.
• "Allowed memory size exhausted": see fixing PHP memory errors.
• Call to undefined function shell_exec, exec or proc_open: those are disabled on shared hosting; see PHP disabled functions.

7. Where Domain India hosting fits

Our cPanel and DirectAdmin plans log PHP errors by default and let you adjust PHP settings per domain with .user.ini, and on cPanel with the MultiPHP INI Editor. Prices on the cards are live and exclude 18% GST.

For full control of php.ini, a VPS lets you set anything, including separate development and production configurations.

Ready to find the error? Start with the logs in section 2, or open a ticket with the page address and the time it failed.