With the complexity of PHP web applications, there are multiple methods to display errors, each with advantages depending on your specific use case.<\/p>\n\n\n\n Before diving into the details of managing and logging errors in PHP, let’s outline the four main ways to display errors in PHP:<\/p>\n\n\n\n All methods are compatible with PHP 8.x. The following additions were made to support modern PHP versions<\/p>\n\n\n\n If you are having problems with your PHP web application and need to display all the errors and warnings, you are in the right place. In this tutorial, we will explain all the different ways to enable PHP errors and warnings. We will also discuss how to write the errors to a log file and even collect them via the Retrace\u2019s error tracking feature<\/a>.<\/p>\n\n\n\n The quickest way to display all php errors and warnings is to add these lines to your PHP code file:<\/p>\n\n\n\n The ini_set function will try to override the configuration found in your PHP ini file.<\/p>\n\n\n\n The display_errors and display_startup_errors are just two of the available directives. The display_errors directive will determine if the errors will be displayed or hidden from the user. Usually, the dispay_errors directive should be turned off after development.<\/p>\n\n\n\n The display_startup_errors, however, is a separate directive because the display_errors don\u2019t handle the errors that will be encountered during PHP\u2019s startup sequence. The list of directives that can be overridden by the ini_set function is found in the official documentation<\/a>.<\/p>\n\n\n\n Unfortunately, these two directives won\u2019t be able to display parse errors<\/strong> such as missing semicolons or missing curly braces. In this case, the PHP ini configuration must be modified.<\/p>\n\n\n\n If adding some of the PHP code errors doesn\u2019t show in the browser during testing, then the PHP ini configuration has some additional directives to handle this.<\/p>\n\n\n\n The display_errors directive must be set to \u201con\u201d in the PHP ini file. This will display all the errors including syntax or parse errors that cannot be displayed by just calling the ini_set function in the PHP code. The PHP ini file can be found in the displayed output of phpinfo() function and is labeled loaded configuration file. This directive in the ini configuration must be set to off, if the web application is in production.<\/p>\n\n\n\n Developers usually have access to the directory files. The directive for showing PHP errors can also be enabled or disabled using the .htaccess file located in the root or public directory of the project.<\/p>\n\n\n\n Similar to what will be added to the PHP code to show PHP errors, .htaccess also has directives for display_startup_errors and display_errors. The advantage of showing or disabling error messages in this manner is that development and production can have different .htaccess files, where the production suppresses the displaying of errors. Sometimes, the warnings that seem not to affect the application at the start will cause some fatal errors in certain conditions. These warnings must be fixed because this means that the application won\u2019t run normally under certain scenarios. In case these warnings cause a lot of errors, then it would be more practical to hide the errors and just show what the warning messages are.<\/p>\n\n\n\n For a developer, showing warnings and hiding errors is just as simple as adding a single line of code. To show warnings and notices, the parameter for the error reporting function will be \u201cE_WARNING | E_NOTICE\u201d. The error_reporting function can accept E_ERROR, E_WARNING, E_PARSE, and E_NOTICE parameters as bitwise operators. To report all errors except for notices, then the parameter is \u201cE_ALL & ~E_NOTICE\u201d where E_ALL stands for all the possible parameters of the error_reporting function.<\/p>\n\n\n\n The error reporting function is a built-in PHP function that allows developers to control which and how many errors will be shown in the application. Remember, the PHP ini configuration has an error_reporting directive that will be set by this function during runtime.<\/p>\n\n\n\n To remove all errors, warnings, parse messages, and notices, the parameter that should be passed to the error_reporting function is zero. It would be not practical to have this line of code in each of the PHP files. It would be better to turn off report messages in the PHP ini file or in the .htaccess.<\/p>\n\n\n\n PHP allows variables to be used even when not declared. This is not a standard practice because undeclared variables will cause issues for the application once it is used in loops and conditions. Sometimes, this also happens because the declared variable has a different spelling than the variable being used for conditions or loops. When E_NOTICE is passed in the error_reporting function, then these undeclared variables will be displayed in the web application.<\/p>\n\n\n\n The error reporting function allows you to filter which errors can be shown. The \u201c~\u201d character means \u201cnot\u201d or \u201cno\u201d so the parameter ~E_NOTICE means not to show notices. Notice the \u201c&\u201d and \u201c|\u201d characters in between the possible parameters. The \u201c&\u201d character is for \u201ctrue for all\u201d, while the \u201c|\u201d character represents either one as long as it is true. These two characters have the same meaning in PHP conditions OR and AND.<\/p>\n\n\n\n These three lines of codes do exactly the same thing, it will show all PHP errors. The error_reporting(E_ALL) is the most widely used among developers to show error messages because it is more readable and understandable.<\/p>\n\n\n\n Consider using E_ALL | E_DEPRECATED for compatibility with PHP 8.x.<\/p>\n\n\n\n During production, error messages must not be shown to the end users, but this information must still be recorded for tracing purposes. The best way to record these error messages on a production web application is to store it in log files.<\/p>\n\n\n\n One easy way to use log files is to use the error_log function, which accepts four parameters. The only required parameter is the first parameter, which contains the details about the error or what\u2019s to be logged. The type, destination, and header are all optional parameters for this function.<\/p>\n\n\n\n The type parameter, if not defined, will be 0 by default, which means this log information will be appended to whatever log file is defined in the web server.<\/p>\n\n\n\n Here, the type 1 parameter will email an error log specified in the third parameter. To make this feature work, the PHP ini must have a proper SMTP configuration to be able to send out emails. These SMTP ini directives include host, encryption type, username, password, and port. This kind of error reporting is advisable to logging or notifying errors that need to be fixed as soon as found.<\/p>\n\n\n\n To log messages in a separate file defined by the configuration of the web server, then type 3 must be used. The third parameter will serve as the location of the log file and must be writable by the web server. The location of the log file can be a relative path to where this code is called or an absolute path.<\/p>\n\n\n\n When working with PHP and AJAX calls, errors can sometimes be difficult to track as they don’t display in the browser directly. Instead, they are returned to the AJAX request. To capture and see these errors, there are a few approaches:<\/p>\n\n\n\n In your JavaScript code, you can add an error handler to your AJAX call. Here\u2019s an example of how you can use console.log()<\/strong> to display any errors that occur during an AJAX request:<\/p>\n\n\n\n In this example, any PHP errors that occur will be displayed in the browser’s developer console via xhr.responseText.<\/strong> This will help you see and troubleshoot errors while working with AJAX calls.<\/p>\n\n\n\n Another way to handle errors in AJAX is to explicitly return error messages from PHP. You can do this by catching exceptions or errors and returning them in a format that your JavaScript can handle, such as JSON:<\/p>\n\n\n\n On the JavaScript side, you can check for these errors and handle them appropriately.<\/p>\n\n\n\n To avoid changing parameters in the .htaccess or adding some lines in the PHP code to show errors, then the best way to log errors is defining it in the web server configuration file.<\/p>\n\n\n\n For Apache, these files must be added to the virtual host of the specific website or application. This is usually located inside the sites-available folder for Ubuntu or httpd-vhosts file in Windows.<\/p>\n\n\n\n For nginx, similar to Apache, the directive is just called error_log. For both Apache and nginx web servers, the log files must be writable by the web server. Luckily, upon installation, the folders for the log files of these two web servers are already writable.<\/p>\n\n\n\n As PHP continues to evolve, newer methods and directives have been introduced to handle error reporting more efficiently in various environments, especially for development versus production settings. Below are some modern approaches and tools you might consider using:<\/p>\n\n\n\n While ini_set()<\/strong> has been around for a while, modern PHP practices encourage its use for more granular control over error reporting. For instance, you can disable error display for production while logging all errors to a secure file location:<\/p>\n\n\n\n In modern PHP, handling errors using exceptions is considered a best practice, especially for larger applications. PHP 8.x allows developers to handle most types of errors as exceptions, offering more control over how errors are managed:<\/p>\n\n\n\n PHP 8.x supports logging errors to remote servers, which is useful for centralized logging in distributed applications. This can be done via syslog or external logging services:<\/p>\n\n\n\n Retrace<\/a> is an APM (Application Performance Management) tool offered by Stackify. But the tool goes beyond monitoring the performance of your application. It allows you to do centralize logging<\/a>, perform code profiling<\/a>, and stay on top of server and application metrics<\/a>.<\/p>\n\n\n\n One of the great features of Retrace<\/a> is its ability to automatically collect all unhandled errors in your PHP application<\/a>. Our PHP extension will catch the exception and forward them automatically to Retrace.<\/p>\n\n\n\n![\"Error](\"https:\/\/stackify.com\/wp-content\/uploads\/2024\/09\/Error-messages-provide-vital-information-about-issues-that-occur-while-running-a-PHP-script.png\")
<\/figure>\n\n\n\nFour different ways to display errors in PHP<\/h2>\n\n\n\n
\n
\n
<\/a>Quickly Show All PHP Errors<\/h2>\n\n\n\n
ini_set('display_errors', 1);\nini_set('display_startup_errors', 1);\nerror_reporting(E_ALL);\n<\/pre>\n\n\n\n<\/a>What Do These Lines of Code Do Exactly?<\/h4>\n\n\n\n
Configure PHP.ini to display all errors<\/h3>\n\n\n\n
display_errors = on<\/pre>\n\n\n\n
Display PHP errors via .htaccess configuration<\/h3>\n\n\n\n
php_flag display_startup_errors on\nphp_flag display_errors on<\/pre>\n\n\n\n
Depending on which files you have access to and how you do deployments and server configurations, you may want to configure display_errors in .htaccess or your PHP.ini file. Many hosting providers will not allow you to modify your PHP.ini file to enable display_errors.
In the .htaccess file, a custom error log can also be enabled as long as the log folder or the log file is writable by the web server. The log file can be a relative path to where the .htaccess is located, or it can be an absolute path such as \/var\/www\/html\/website\/public\/logs.<\/p>\n\n\n\nphp_value error_log logs\/all_errors.log<\/pre>\n\n\n\n
Enable detailed warnings and notices<\/h3>\n\n\n\n
error_reporting(E_WARNING);<\/pre>\n\n\n\n
In-depth with the error_reporting() function<\/h3>\n\n\n\n
error_reporting(0);<\/pre>\n\n\n\n
error_reporting(E_NOTICE);<\/pre>\n\n\n\n
error_reporting(E_ALL & ~E_NOTICE);<\/pre>\n\n\n\n
error_reporting(E_ALL);\nerror_reporting(-1);\nini_set('error_reporting', E_ALL);<\/pre>\n\n\n\nLog PHP errors to a file using the error_log() function<\/h3>\n\n\n\n
![\"The](\"https:\/\/stackify.com\/wp-content\/uploads\/2024\/09\/The-best-way-to-record-these-error-messages-on-a-production-web-application-is-to-store-it-in-log-files.png\")
<\/figure>\n<\/figure>\n\n\n\nerror_log(\"There is something wrong!\", 0);<\/pre>\n\n\n\n
error_log(\"Email this error to someone!\", 1, \"someone@mydomain.com\");<\/pre>\n\n\n\n
error_log(\"Write this error down to a file!\", 3, \"logs\/my-errors.log\");<\/pre>\n\n\n\n
Handling PHP Errors in AJAX Calls<\/h3>\n\n\n\n
1. Use console.log()<\/strong> in the AJAX error handler<\/h4>\n\n\n\n
$.ajax({ \nurl: 'your-php-script.php', \nmethod: 'POST', \ndata: { key: 'value' }, \nsuccess: function(response) { \nconsole.log('Success:', response); \n}, \nerror: function(xhr, status, error) { \nconsole.log('AJAX Error:', xhr.responseText); \n} \n});<\/code><\/pre>\n\n\n\n2. Return error responses from PHP<\/h4>\n\n\n\n
try { <\/code><\/pre>\n\n\n\n\/\/ Your PHP code <\/code><\/pre>\n\n\n\n} catch (Exception $e) { <\/code><\/pre>\n\n\n\necho json_encode(['error' => $e->getMessage()]); <\/code><\/pre>\n\n\n\nhttp_response_code(500); <\/code><\/pre>\n\n\n\n}<\/code><\/pre>\n\n\n\nLog PHP errors through the web server configuration<\/h3>\n\n\n\n
ErrorLog \"\/var\/log\/apache2\/my-website-error.log\"<\/pre>\n\n\n\n
error_log \/var\/log\/nginx\/my-website-error.log;<\/pre>\n\n\n\n
Modern Methods for Handling PHP Errors<\/h2>\n\n\n\n
1. Using ini_set() for More Granular Control<\/h3>\n\n\n\n
ini_set('display_errors', 'Off'); <\/code><\/pre>\n\n\n\nini_set('log_errors', 'On'); <\/code><\/pre>\n\n\n\nini_set('error_log', '\/path\/to\/secure\/error.log'); <\/code><\/pre>\n\n\n\nerror_reporting(E_ALL | E_STRICT);<\/code><\/pre>\n\n\n\n2. Error Handling with Exceptions in PHP 8.x<\/h3>\n\n\n\n
try { <\/code><\/pre>\n\n\n\n\/\/ Code that may throw an error <\/code><\/pre>\n\n\n\n} catch (Error $e) { <\/code><\/pre>\n\n\n\nerror_log($e->getMessage()); <\/code><\/pre>\n\n\n\n\/\/ Handle the error, e.g., by showing a user-friendly message <\/code><\/pre>\n\n\n\n}<\/code><\/pre>\n\n\n\n3. Using error_log() for Remote Logging<\/h3>\n\n\n\n
error_log(\"Application error\", 0, \"syslog\"); \/\/ Logs to syslog <\/code><\/pre>\n\n\n\nerror_log(\"Application error\", 0, \"udp:\/\/logs.example.com:514\"); \/\/ Logs to a remote syslog server<\/code><\/pre>\n\n\n\nAutomatically collect PHP errors with Retrace APM<\/h3>\n\n\n\n
![\"show](\"https:\/\/stackify.com\/wp-content\/uploads\/2020\/03\/php-errors-2020-1024x344.png\")
<\/figure>\n\n\n\n