One of the great things about PHP is its flexibility and options. One of the bad things about PHP is its flexibility and options. The result is that programmers can’t be 100% sure what the conditions are (think php.ini options) that their software will be running under. So here are some tips that every PHP programmer should keep in mind, specifically while in development mode:
- Magic Quotes: Ideally set this via .htaccess with php_value, either on or off, which ever way you want to work with your data. My personal preference of late is to turn this off and make sure that my code escapes everything. This avoids trying to guess when you need to escape something and when you don’t. This can be tricky when you have systems (databases usually) that have different formats for escaping quotes. Look at magic_quotes_gpc and magic_quotes_runtime settings.
- Error Level: There are multiple error levels in PHP. When you are in development mode please, please, please set this to E_ALL (or maybe even to E_STRICT if you are using PHP 5). This can be done from within your code using the error_reporting() function. Once you are ready to make a release of your software you can turn the error level down if you want.
- Display Errors: Along with cranking up the errors, displaying them makes them pretty obvious during the development process. This is also easily turned on using the ini_set() function. This is all it takes:
ini_set('display_errors', '1');. This one isn’t quite as big a deal as the others because there is nothing wrong with watching errors in a log file, but I’ve found that if the errors aren’t being displayed in the page they are often forgotten about. And again, this is something that can be turned off when you make a release of your software. But if you’ve fixed all of the bugs that display errors or warnings then you shouldn’t need to :-)
So when an error pops up in your page, don’t just turn off display errors or lower the error level, fix it. These settings I recommended above are the default for PHP on my systems, so if you have warnings and errors in your code they end up all of the page when I run your software. This makes your software look pretty low in the quality department. Keep in mind that as the author of a software package, you don’t know what people will have these options set to on their server, so your software should force them to a known value that you can rely upon.
I’ve been putting off this little rant for quite sometime, but lately the number of software packages that I’ve tried out that ignore one or all of the above suggestions was really high. In some cases large security holes were opened because of these assumptions (think magic quotes and sql injection attacks). Following these suggestions is much easier if you implement them at the beginning of a project instead of after version 1.0 has already shipped.