One of the big causes of errors in PHP scripts is the lack of a portable code standard. In this article, Derek takes a look at a few little things that we can do to help make our PHP scripts more portable. When other developers comes to use them, they will have more of a chance of working successfully the first time, without the need to perform any kind of system configuration modifications, etc.
Tips For Making Your PHP Code More Portable - PHP Tags (Page 2 of 4 )
When you're creating blocks of PHP code, do you use <? or <% as your PHP opening tags? If you do, then stop it immediately! Always use the default, fully open tag: <?PHP. Both the short and ASP styles of code block tags can be turned off in the php.ini file, however the long method cannot.
As of PHP version 4.0.3, GPC variables can be found in the $HTTP_*_VARS arrays. Because register_globals can be turned off (in PHP4+), you should never treat GPC's as if they're normal global variables. For example, if you had a <form> tag with its method attribute set to post, and a text field named "foo", then you shouldn't use $foo to refer to the value of this form variable in your PHP scripts, but rather the $HTTP_POST_VARS['foo'] associative array value. Using global variables can cause some major security issues rather easily. Stay way from register_globals too; they are the devil in disguise.
If magic_quotes_gpc is enabled in your php.ini file (which it is by default), then your GPC data will have backslashes prepended before characters that need to be escaped for database queries etc. These characters are the single quote ( ' ), the double quote ( " ), the backslash ( \ ), and NULL (the NULL byte with character code zero). If you turn off magic_quotes_gpd in your php.ini file, then you will notice a slight performance gain.
Here's a simple solution that you should use when building SQL queries that use GPC variables:
$query = 'UPDATE mytable SET myfield=\'' . slashes($HTTP_POST_VARS['myfield']) . '\'';
By default, the error_reporting option in the php.ini file is set to "E_ALL & ~E_NOTICE". This suppresses error messages that are generated for non-critical errors. For example, if you use a variable that hasn't been initialized, then you won't see an error. Is this a good thing? Well not really, since some people could have their error_reporting set to "E_ALL", meaning that they would see an error if a variable is used and not initialized. The solution is to set the value of the "error_reporting" attribute in your php.ini file to "E_ALL" when developing.