I fixed a problem today where custom blog software had stopped working after a permissions update. A large number of sites are based upon the blog software and they were all down. Blank page. No errors on screen or in the logs.
This was not software and I came in knowing nothing about it. It might've helped that I do know the developer, but he was offline and unreachable, and no longer with the company for which the software was created. Panic was setting in with customer service.
It's really frustrating when error reporting is turned completely off and no other error handling has been implemented. I knew the problem must be permissions related but there was just no clue as to what file was failing to write. I also knew the application was Zend Framework, which I've been working with for about a year or so. A quick change to the application.ini ...
phpSettings.display_errors = 1
phpSettings.error_reporting = 1
... and I was to see the error and correct the permissions.
This brings to mind: The Log File is Your Friend. Frameworks or applications that implement their own error handling need to also find a way of silently indicating the problem. In this case, it could be done in a custom manner using Zend_Log or by adding log_errors to the php.ini file or to application.ini, like so:
phpSettings.error_reporting = 1024
phpSettings.log_errors = 1