In a post to his site Leonid Mamchenkov shares an interesting output bug he came across in his work developing cron jobs and how they handled his errors.

We came across this PHP bug at work today. But before you go and read it, let me show you a use case. See, if you can spot the problem. We had a cron job script which [ran a PHP script and echoed a string when complete].

[...] We use similar code snippets all over the place, and they work fine. This particular one was a new addition. So the cron job ran and “Updating products failed” part happened. Weird. The PHP script in question has plenty of logging in it, but nothing was logged.

After adding more and more logging to the process and PHP script, nothing obvious was standing out. Finally, they noticed that the filename was incorrect but normally that would cause an error in the PHP command line execution. The tricky part here was in how PHP handled its errors. Their error_log and display_errors settings were such that the PHP "missing file" error was being swallowed up and not displayed.

Douglas Brown has posted some hints to help you find errors in your PHP scripts all centered around error reporting settings.

There are several methods to solve errors in PHP code. Sometimes when the user waits to see an output a blank page will be shown if there is an error. To show the errors E_ALL^E_STRICT is used for the PHP 5 version. Contrarily, remaining versions just use E_ALL.

He talks about the log_errors and display_errors settings in your php.ini, the error_reporting function call or a custom error handler as shown in this example from the PHP manual.

In a response to this post on the PHP 10.0 Blog, Richard Heyes offers a method for what Stas was wanting:

OK, then what we do if something weird happens in production and we want to see the errors, but we don’t want others to see them? [...] Maybe PHP could have some setting like display_errors=local which would enable display_errors for requests originating from developer machine but would disable it when outsider accesses it?

Richard's solution checks the HTTP_HOST value of the current request and, based on whether it's marked as "live" or "dev", uses a ini_set to change the display_errors setting to true/false.

In an effort to get some thought going about ways to encourage security in PHP applications, Stas has posted an idea about a simplified php.ini setting - production=On.

His idea is that, with this setting on, the PHP installation would:

• disable display errors
• disable phpinfo()
• turn expose_php off
• make max_execution_time/memory_limit reasonable
• and possibly a few others that some developers forget to set correctly

In an effort to get some thought going about ways to encourage security in PHP applications, Stas has posted an idea about a simplified php.ini setting - production=On.

His idea is that, with this setting on, the PHP installation would:

• disable display errors
• disable phpinfo()
• turn expose_php off
• make max_execution_time/memory_limit reasonable
• and possibly a few others that some developers forget to set correctly