
When you write PHP scripts and test them locally, you probably set PHP to show all errors, for easier debugging.
But if, when you use them on a “live” server, you use the “@” operator to suppress errors, then take note of the following…
Error suppression in PHP is very slow
Get rid of all your error suppressing mechanisms, because it slows down your script.
Of course you still need to know where your application crashes, so you need a debug mode, eh? No problem, here’s the…
Use the following code to be able to change from a debug environment (show all errors) to a “live” environment (show no errors)
<?php
if(isset($_GET['debugenv'])) {
error_reporting(E_ALL); //show all errors
ini_set('display_errors', '1');
}
else
error_reporting(0); //show no errors
?>
As simple as that. Now, access your site just as you’d normally do, but if you want to debug something, append ?debugenv=1 to your url. Good luck!
If you would like to make a comment, please fill out the form below.
Security-wise this is a bad idea. Anybody can turn on debugging on your website so when they find a bug, they will learn much more about your code and your server.
You can improve it by making sure that the only person who can turn debugging on is YOU. If you have a static IP address, check that it is yours as well as checking the debug variable. If not, you will probably have to create a password protected page that turns debugging on and off for anyone with your session ID.
Hi, Dave, and thank you for your interest in contributing. Well, the code I posted is just for the sake of giving an example. Ofcourse, user-input data should (oh wait - MUST) be sanitised, cleansed of all “evil” code, sql injection and so on.
To continue your idea: if you have a site with a login mechanism, that shouldn’t be a problem. Allow only some users (or a user class) to switch debugging on or off and you’re done ;)