PHP Tips and Tricks

These are some common PHP and MySQL coding tips.
I believe these are good do's and don'ts, that most experienced coders would agree with, and not just my opinions.

Note: in my examples, I'm using the new arrays ($_GET/$_POST/$_COOKIE/$_SERVER) because I'm assuming that you're using at least PHP 4.1.0. If you have an older version, then use the old, longer arrays ($HTTP_GET_VARS/$HTTP_POST_VARS/$HTTP_COOKIE_VARS/$HTTP_SERVER_VARS). But you should upgrade because of the file-upload vulnerability in unpatched versions prior to 4.1.2. That's a tip by itself!

__________________
Thanks & Regards
Sabari...

PHP - register_globals

First and foremost, I believe, is the use of register_globals. For those of you who don't know, register_globals allows you to access variables from forms and URLs (such as file.php?var=foo) as $var in your script -- "magically" created global variables.

Unfortunately, this old method continues to be used in most tutorials/examples. The PHP developers seem to have realized that register_globals was a bad idea, though. They discuss Using Register Globals in the PHP manual and recommend turning them off in php.ini:
Quote:

Note that register_globals is going to be deprecated (i.e., turned off by default) in the next version of PHP, because it often leads to security bugs.
...
You should do your best to write your scripts so that they do not require register_globals to be on


In fact, as of PHP 4.2.0, register_globals is now off by default on new PHP installations. By writing code that relies on register_globals being on, you risk having that code not work on some systems! Wouldn't you rather use the preferred method of accessing variables and have your code work on all PHP installations?

The proper way to access these variables is via their respective arrays. So instead of $var, in the above example, you should use $_GET['var']. Similarly, use $_SERVER['HTTP_USER_AGENT'] instead of just $HTTP_USER_AGENT.

The main arrays are $_GET, $_POST, $_COOKIE, and $_SERVER, depending on where the variable came from, obviously. You can read more about them, and a couple of others, here and here in the manual.

Please access your variables via these arrays!

__________________
Thanks & Regards
Sabari...

magic_quotes, addslashes(), and stripslashes()

magic_quotes_gpc, when on, automatically adds slashes to all GET/POST/COOKIE data so that you don't need to use addslashes() before using GET/POST/COOKIE data in MySQL queries, etc. (e.g. with magic_quotes_gpc OR addslashes(), I'm becomes I\\'m). Well, magic_quotes_gpc is no convenience and just complicates things!

Since magic_quotes_gpc can be on or off, you don't know whether to use addslashes() or not. You don't want to use addslashes() when magic_quotes_gpc is on because you'll add too many slashes (e.g. I'm becomes I\\\\'m), which is bad. Use addslashes() if magic_quotes_gpc is off, and don't if it's on (you can find out its setting with get_magic_quotes_gpc()). But you can't use the same code all the time. One workaround is something such as:

if (!get_magic_quotes_gpc()) { $txt = addslashes($txt); }
Things are further complicated if you want to first manipulate text that has had magic_quotes_gpc applied. You then have some text that has slashes added and some that doesn't. The effect of this is: some text will be wrong whether you use addslashes() or not.

It's easiest to turn off magic_quotes_gpc, which I recommend, and use addslashes() manually all the time and not worry about the wrong amount of slashes. This is what it says in the recommended php.ini:
Quote:

magic_quotes_gpc = Off

Input data is no longer escaped with slashes so that it can be sent into SQL databases without further manipulation. Instead, you should use the function addslashes() on each input element you wish to send to a database.

As I said above, if you use addslashes() when magic_quotes_gpc is on, too many slashes will be added. For inserting I'm into MySQL, you want it to be I\\'m (and it will come out as I'm). Using addslashes() with magic_quotes_gpc, however, will give you I\\\\'m. THAT will come out of MySQL as I\\'m, which is not the original text. Most people assume that you are supposed to use stripslashes() when retrieving data from MySQL because otherwise they have slashes in their text. But that's fixing a problem that should never have occurred. If you have to use stripslashes() on text from your database, it's because you added too many slashes when you inserted it. You should never have to use stripslashes() on text from your database. If you do, you need to fix the problem at the source, rather than after the fact.

You can turn off magic_quotes_gpc in php.ini or like this in a .htaccess file:

<IfModule mod_php4.c> php_flag magic_quotes_gpc off </IfModule>

If that's not possible, you can put the following code at the top of all your files (in a require or include). It will strip the slashes that magic_quotes_gpc added, virtually turning it off.


function strip_magic_quotes($arr)
{
foreach ($arr as $k => $v)
{
if (is_array($v))
{ $arr[$k] = strip_magic_quotes($v); }
else
{ $arr[$k] = stripslashes($v); }
}

return $arr;
}

if (get_magic_quotes_gpc())
{
if (!empty($_GET)) { $_GET = strip_magic_quotes($_GET); }
if (!empty($_POST)) { $_POST = strip_magic_quotes($_POST); }
if (!empty($_COOKIE)) { $_COOKIE = strip_magic_quotes($_COOKIE); }
}

__________________
Thanks & Regards
Sabari...

ereg vs preg

When it comes to the regular expression functions, ereg* and preg*, the preg functions are the clear choice. The preg functions are generally twice as fast as their ereg counterpart. They also support more advanced regular expression operations. I can't think of any reason why you would need to use the ereg functions.

preg manual page and pattern syntax (long and confusing but pretty good).

__________________
Thanks & Regards
Sabari...

PHP tags

I recommend always using the full PHP open tag, <?php, rather than the short one, <?. This means also that instead of <?=$var?>, it's better to use the full <?php echo $var?>. Using the full open tag ensures that your code will work on all PHP installations, regardless of the short_open_tag setting.

__________________
Thanks & Regards
Sabari...

Alternative control structure syntax

I highly recommend staying away from the if (): ... endif; style syntax and sticking with curly braces, if () { ... }. This is the preferred syntax and it makes your code easier to read.

__________________
Thanks & Regards
Sabari...

error_reporting

You should probably test your code with error_reporting set to at least E_ALL & ~E_NOTICE (all errors except notices) so that you aren't suppressing errors that should be fixed. error_reporting can be set in php.ini or with the error_reporting() function.

__________________
Thanks & Regards
Sabari...

Line breaks

People want to know how they can retain textarea line breaks in HTML. You should store text in the database in its original format (e.g. with just newlines) and then use nl2br() to convert newlines to HTML <br /> tags on display. That's all good, except for one problem with nl2br(): it doesn't seem to convert \r newlines (edit: this has now been fixed in PHP 4.2.0).

Windows uses \r\n newlines; *nix uses \n; Mac uses \r.

nl2br() works correctly on text from Windows/*nix because they contain \n. However, if you get text from a Mac, nl2br() will not convert its newlines (again, fixed in PHP 4.2.0). To remedy this, I use the following bit of code to convert \r\n or \r to \n before inserting it into the database. It won't hurt anything and ensures that nl2br() will work on the \n only newlines on display. Also, it has the side effect of saving 1 byte in the database per newline from Windows (by storing only \n instead of \r\n).


$txt = preg_replace('/\r\n|\r/', "\n", $txt);

__________________
Thanks & Regards
Sabari...

Strings

1) As a finesse thing, I use single quotes around strings whenever possible (e.g. strings that don't contain variables, single quotes, \n, etc.). This is supposed to make less work for the PHP parser.

2) When an array variable isn't in a string, put quotes around string-literal keys so they are not regarded as constants:


// OK
echo $row[$key];

// Wrong, unless key is a constant
echo $row[key];

// Right
echo $row['key'];

// OK, since it's in a string
echo "Text: $row[key]";

3) Remember, you can break out of PHP mode for large sections of HTML. This is faster than echo'ing and you don't need to escape quotes.

__________________
Thanks & Regards
Sabari...

Quotes around numeric data in queries

For numeric columns in MySQL, you shouldn't put quotes around any of their values in queries. As our resident database guru, MattR, says, "that is very non-standard and will only work on MySQL." But if it's unknown data, how do you know that it's numeric and not letters that will cause an error? You can make sure that only a number is used in the query by first type-casting the data as int (or float for decimal numbers):


// If id is being passed in the URL
$id = (int) $_GET['id'];

$r = mysql_query("SELECT * FROM table WHERE id=$id");

Then even if id is set to "abc," the worst that can happen is a 0 will be used in the query. No quotes; no error.

__________________
Thanks & Regards
Sabari...