Why Is It that Joomla Sometimes Doesn’t Show the Errors Even if Error Reporting Is Set to Maximum?

If you have have been working on Joomla for a long time, then most likely you ran into the situation where you’re seeing a blank page instead of your homepage. Under normal circumstances, changing the Error Reporting value (under Site -> Global Configuration -> Server) to Maximum will show the error(s) that is(are) causing the blank page issue. However, sometimes doing that will change nothing, you will still see a blank page.

Why?

Well, there are 2 causes of this issue:

1. The @ error control operator: The @ error control operator, when prepending a PHP expression, will suppress all notices/warnings/errors that are incurred on that PHP expression. The only scenario where the @ control operator won’t work is when the PHP expression has a parse error.

   In 99% of the cases, the @ error control operator is not the cause of the blank page, simply because it is strictly used to suppress warnings, and not errors. But for the 1% of the cases where the @ error control operator is the cause of the blank page, it will be a nightmare to locate where the actual problem is. In short, you will have to search for all the files that contain the @ operator at the beginning of a line, and then debug these files one by one.

   Generally, we think that the usage of the @ error control operator indicates weak coding skills, so, if you have an extension that use it extensively, then you are better of with another extension that does more or less the same thing but coded more professionally.

2. Output buffering: Before discussing this issue, let us explain, concisely, what is output buffering. PHP (the programming language that powers Joomla), by default, will send the output to the browser immediately when it is instructed to do so (for example, using the echo statement). If output buffering is turned on, then any output after the ob_start function call will be stored in a variable that is later retrieved using the function ob_get_contents. Note that output buffering will only end when ob_end_flush or ob_end_clean are called.

   Now, you might be wondering, why use output buffering?

   In the majority of scenarios, output buffering is used to ensure that you don’t see the “headers already sent” error or if you want to manipulate the output prior to displaying it (there’s also claims that the output processing will be faster because it’ll be done in one shot, but we reckon that the benefit claimed is negligible, if there’s one). The problem, however, is that since output buffering holds all output until the buffering ends, then you can’t see the (fatal) error if it happens before the buffering ends, and so you will see a blank page that will not go away even if you set the Error Reporting to Maximum.

   On the bright side, there are several ways to find what the error is (note that you must change Error Reporting to Maximum in your configuration for the below to work):

   1. Disable output buffering at the .htaccess level: All you need to do is open the .htaccess file, and then add the following line to the top:

      php_flag "output_buffering" off

      Adding the above line will ensure that output buffering will no longer work, and so you will see all the errors on your Joomla website.

   2. Disable output buffering in the php.ini file: You can disable output buffering by adding the following line to your php.ini file:

      output_buffering = Off

      Note that it is recommended that you disable output buffering at the site level, by copying the php.ini file to the root directory of your website, and then changing the setting there. This will ensure that you won’t affect other sites (that may need output buffering to work properly) running on the same server. Also note that this is equivalent to the above action, so, if you have the choice, then it’s better to disable output buffering in the .htaccess file (using the above method) instead of overriding the php.ini file.

   3. Search the filesystem for any instance of ob_start and comment it out: This is a tricky solution because you will then need to revert your changes once you find the culprit, but it will work.

   4. Instruct PHP to log errors to a file: Modify the php.ini file to log errors to a certain file by adding the following line:

      log_errors=/tmp/errors.log

      The above line will ensure that all errors are stored in the errors.log file under the tmp directory. You can then check the log file to see what the real error is.

   Note that the methods a & b above will most likely display errors about functions needing output buffering turned on. If this happens, then you will need to comment out those function calls as described in method c.

We hope that our post helped you in finding out what the mysterious cause of the blank page is. If you still can’t find out what the root cause is, even after applying all the above solutions, then please contact us. We’ll definitely find where the problem is in very little time and for a very affordable fee! What are your waiting for? Give us a call or shoot us an email!