We have a few sites running on a dedicated server and have just upgraded to PHP 5.3.2 which has in turn changed the error reporting level to 22527. Since the change I’m getting no error reports, just a blank page, which I guess is because display_errors is off.
So, if I were to turn display_errors on in php.ini, what would be a sensible error_reporting value?
On the other hand, the PHP manual suggests display_errors should be off for live sites, so if I do that, how do I get meaningful errors?
Yeah, I do tend to work on a local server but there comes a point where it’s easier to work on the live server.
One other slight issue is that this particular server runs Windows so I don’t have the .htaccess/http.conf option, unless there’s another way of doing it.
in the ini file
in a .htaccess file
in individual files or includes
So you have amazing granularity about whether to show them or not, or whether to log them or ignore etc.
During development are you not working on a local server which you control? So you turn error reporting right up, show everything and sort the problems out.
On your live server, read the values from your ini file ( using [fphp]ini_get[/fphp] ) and take action to override it by domain/folder/file.
Thanks Cups, but yesterday afternoon (before I posted) the search on this forum wasn’t working for some reason, but I did try! I just followed your link and found the link to your old thread from a couple of years ago too.
Problem is, I don’t have direct access to php.ini, but can ask for changes to be made. So how about I get display_errors turned on, show E_ALL (and maybe E_STRICT) during development, then turn display_errors off using ini_set when the site is live, logging errors to a file?
The only problem I can see is that fatal errors will still be displayed, but I can’t actually think of any occasions where I’ve had a fatal error on a live site. I’m prepared to be shot down though…
Real men use E_ALL + E_STRICT for their error reporting level in development.
Once you deploy ideally you have a capturing routine that logs the errors and returns a response back to the user that allows them to recover. Simply turning display errors off will often dump them to a blank screen which is unacceptable.
Reacting to errors isn’t a security risk in and of itself. Displaying chatty error messages is. If an error does occur the user needs to be aware of it, why they can’t proceed and perhaps what they can do next. Raw PHP errors shouldn’t go through as giving path information on your files is a security risk (a mild one, but not an insignificant one).
I mean, in my own code an error in dev echos back the error, a backtrace, the queries that got ran, the $_POST, $_GET and the $_SESSION, and finally the included files list. All that is NOT something I (or anyone sane) wants seen in production. In production that information is logged onto the errors table (if the database deployed) or to a log file (if the db isn’t available). The user gets a 500 Internal server error with appropriate headers (so the browser doesn’t cache the error page) and that error page explains the public information about the error (usually an “I’m sorry but there was a problem with your request” sort of error). The error page has links to other parts of the site so the user can navigate away from the page.
I consider error reporting to be a potential security risk. I always have it set to off on my production websites. It is possible to log PHP errors to a text file. You could use that for debugging.
