Latest TweetsVerify any search engine or visitor via CLI Forward-Reverse Lookup perishablepress.com/cli-forwar…
Perishable Press

Advanced PHP Error Handling via htaccess

In my previous article on logging PHP errors, How to Enable PHP Error Logging via htaccess, we observed three fundamental aspects of preventing, preserving, and protecting your site’s PHP errors.

Prevent public display of PHP errors via htaccess

# supress php errors
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off
php_value docref_root 0
php_value docref_ext 0

Preserve (log) your site’s PHP errors via htaccess

# enable PHP error logging
php_flag  log_errors on
php_value error_log  /home/path/public_html/domain/PHP_errors.log

Protect your site’s PHP error log via htaccess

# prevent access to PHP error log
<Files PHP_errors.log>
 Order allow,deny
 Deny from all
 Satisfy All
</Files>

Now, in this article, we will explore these operations1 in greater depth, provide additional functionality, and examine various implications. First we will explore PHP error handling for production environments (i.e., for websites and applications that are online, active, and public), then we will consider error handling for development environments (i.e., for projects that are under development, testing, private, etc.).

Controlling the level of PHP error reporting

Using htaccess, it is possible to set the level of error reporting to suit your particular needs. The general format for controlling the level of PHP errors is as follows:

# general directive for setting php error level
php_value error_reporting integer

There are several common values used for “integer”, including:

  • Complete error reporting — for complete PHP error logging, use an error-reporting integer value of “8191”, which will enable logging of everything except run-time notices2.
  • Zend error reporting — to record both fatal and non-fatal compile-time warnings generated by the Zend scripting engine, use an error-reporting integer value of “128”.
  • Basic error reporting — to record run-time notices, compile-time parse errors, as well as run-time errors and warnings, use “8” for the error-reporting integer value.
  • Minimal error reporting — to record only fatal run-time errors, use an error-reporting integer value of “1”, which will enable logging of unrecoverable errors.

Of course, there are many more error-reporting values available, depending on your particular error-logging goals. For more information on logging PHP errors, refer to the Error Handling and Logging Functions page at php.net.

Setting the maximum file size for your error strings

Using htaccess, you may specify a maximum size for your PHP errors. This controls the size of each logged error, not the overall file size. Here is the general syntax:

# general directive for setting max error size
log_errors_max_len integer

Here, “integer” represents the maximum size of each recorded error string as measured in bytes. The default value is “1024” (i.e., 1 kilobyte). To unleash your logging powers to their fullest extent, you may use a zero value, “0”, to indicate “no maximum” and thus remove all limits. Note that this value is also applied to displayed errors when they are enabled (e.g., during development).

Disable logging of repeated errors

If you remember the last time you examined a healthy (or sick, depending on your point of view) PHP error log, you may recall countless entries of nearly identical errors, where the only difference for each line is the timestamp of the event. If you would like to disable this redundancy, throw down the following code in the htaccess file of your project root:

# disable repeated error logging
php_flag ignore_repeated_errors on
php_flag ignore_repeated_source on

With these lines in place, repeated errors will not be logged, even if they are from different sources or locations. If you only want to disable repeat errors from the same source or file, simply comment out or delete the last line. Conversely, to ensure that your log file includes all repeat errors, change both of the on values to off.

Putting it all together — Production Environment

Having discussed a few of the useful ways to customize our PHP error-logging experience, let’s wrap it all up with a solid, htaccess-based error-handling strategy for generalized production environments. Here is the code for your target htaccess file:

# PHP error handling for production servers
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off
php_flag log_errors on
php_flag ignore_repeated_errors off
php_flag ignore_repeated_source off
php_flag report_memleaks on
php_flag track_errors on
php_value docref_root 0
php_value docref_ext 0
php_value error_log /home/path/public_html/domain/PHP_errors.log
# [see footnote 3] # php_value error_reporting 999999999
php_value error_reporting -1
php_value log_errors_max_len 0

<Files PHP_errors.log>
 Order allow,deny
 Deny from all
 Satisfy All
</Files>

Or, if you prefer, an explanatory version of the same code, using comments to explain each line:

# PHP error handling for production servers

# disable display of startup errors
php_flag display_startup_errors off

# disable display of all other errors
php_flag display_errors off

# disable html markup of errors
php_flag html_errors off

# enable logging of errors
php_flag log_errors on

# disable ignoring of repeat errors
php_flag ignore_repeated_errors off

# disable ignoring of unique source errors
php_flag ignore_repeated_source off

# enable logging of php memory leaks
php_flag report_memleaks on

# preserve most recent error via php_errormsg
php_flag track_errors on

# disable formatting of error reference links
php_value docref_root 0

# disable formatting of error reference links
php_value docref_ext 0

# specify path to php error log
php_value error_log /home/path/public_html/domain/PHP_errors.log

# specify recording of all php errors
# [see footnote 3] # php_value error_reporting 999999999
php_value error_reporting -1

# disable max error string length
php_value log_errors_max_len 0

# protect error log by preventing public access
<Files PHP_errors.log>
 Order allow,deny
 Deny from all
 Satisfy All
</Files>

This PHP error-handling strategy is ideal for a generalized production environment. In a nutshell, this code secures your server by disabling public display of error messages, yet also enables complete error transparency for the administrator via private error log. Of course, you may wish to customize this code to suit your specific needs. As always, please share your thoughts, ideas, tips and tricks with our fellow readers. Now, let’s take a look at a generalized error-handling strategy for development environments..

Putting it all together — Development Environment

During project development, when public access to your project is unavailable, you may find it beneficial to catch PHP errors in real time, where moment-by-moment circumstances continue to evolve. Here is a generalized, htaccess-based PHP error-handling strategy for development environments. Place this code in your target htaccess file:

# PHP error handling for development servers
php_flag display_startup_errors on
php_flag display_errors on
php_flag html_errors on
php_flag log_errors on
php_flag ignore_repeated_errors off
php_flag ignore_repeated_source off
php_flag report_memleaks on
php_flag track_errors on
php_value docref_root 0
php_value docref_ext 0
php_value error_log /home/path/public_html/domain/PHP_errors.log
# [see footnote 3] # php_value error_reporting 999999999
php_value error_reporting -1
php_value log_errors_max_len 0

<Files PHP_errors.log>
 Order allow,deny
 Deny from all
 Satisfy All
</Files>

For this code, we will forego the line-by-line explanations, as they may be extrapolated from the previous section. This PHP error-handling strategy is ideal for a generalized development environment. In a nutshell, this code enables real-time error-handling via public display of error messages, while also enabling complete error transparency for the administrator via private error log. Of course, you may wish to customize this code to suit your specific needs. As always, please share your thoughts, ideas, tips and tricks with our fellow readers. That’s all for this article — see you next time!

Useful Links

Footnotes

  • 1 For more information, check out the manual on Error Handling and Logging Functions at php.net
  • 2 Due to the bitwise nature of the various error-reporting values, the value for logging all errors continues to increase. For example, in PHP 5.2.x, its value is 6143, and before that, its value was 2047. Thus, to ensure comprehensive error logging well into the future, it is advisable to set a very large value for error_reporting, such as 2147483647.
  • 3 According to the PHP Manual on error_reporting, “Passing in the value -1 will show every possible error, even when new levels and constants are added in future PHP versions. The E_ALL constant also behaves this way as of PHP 6.” – Thus, the code in this article has been updated accordingly. Simply delete the commented-out line in the code and you’re good to go.

Jeff Starr
About the Author Jeff Starr = Creative thinker. Passionate about free and open Web.
Archives
22 responses
  1. That’s quite a good idea; too bad it’s not working on my shared hosting :/

  2. Jeff Starr

    Hi Louis,

    As discussed elsewhere, it seems that PHP error logging has, for whatever reason, been disabled on your shared hosting account. I assure you, these are standard methods that will work (I use them myself) on any capable server.

  3. Thanks for tips … it worked on my (only ftp access) server.

  4. Jeff Starr

    Sure thing, styx — thanks for the feedback! ;)

  5. Just wanted to say thanks for such a succinct and informative article. This is *exactly* what I needed to know. Very much appreciated.

  6. Jeff Starr

    My pleasure! I am very glad this article has proven helpful for you. Thank you for the positive feedback! :)

  7. Christelle March 20, 2008 @ 1:25 pm

    Very nice job to put all the information together with adequate explanations. Thanks indeed !

  8. Jeff Starr

    Happy to help, Christelle — thanks for the feedback! :)

  9. A bit earlier I came accross of a very basic error handling instruction.
    But your articles gives so much more – an excelent in-depth tutorial for a newbie. And surprisingly it is easy to understand and it does work!! [5 stars!]
    Thank you, Perishable

  10. Jeff Starr

    Thank you for the positive feedback, mmdesign! It is much appreciated! :)

  11. Ben Johnson May 8, 2008 @ 3:20 pm

    Great article, and much-needed information, especially for new developers.

    A couple of points of note, however.

    1.) You should not use the

    # specify recording of all php errors
    php_value error_reporting 999999999

    because that causes the error output that should ONLY be logged to be sent to the browser on many POSIX systems! Visitors to the site will see every single error PHP is logging, right in the browser window on every page!

    Instead, you should use E_ALL, or a combination of the predefined constants. Using ANY integer value in this case is a bad idea, since they are subject to change. That is precisely why the constants exist!

    2.) There is a small syntax error in your sample file (you forgot the php_value at the very bottom):

    # disable max error string length
    log_errors_max_len 0

    should instead be

    # disable max error string length
    php_value log_errors_max_len 0

  12. Jeff Starr

    Hi Ben, thank you for sharing this information. I had no idea that POSIX systems behaved this way. Question: is it safe to use error_reporting given large enough reporting values on non-POSIX systems? I am trying to keep this article as general as possible, without requiring too much fiddling with various predefined-constant configurations. Perhaps simply replacing error_reporting with E_ALL would do the trick? In either case, I am going to revise the article to reflect this information and will post a followup comment here as well to signal the update.

    Also, thanks for the catch on the missing php_value. There were two three instances of this omission and both all have now been corrected. Thank you! :)

[ Comments are closed for this post ]