Keeping Code Up-to-Date

When managing websites, keep in mind that the Internet doesn't sit still. That PHP script written 10 years ago probably has a thing or two needing to be updated. There may be security issues, outdated code, etc. In addition to the evolution of programming / scripting languages, you as a developer have likely changed. Your coding practices are likely to be more efficient and more secure. So let's look at why we need to review old scripts on a semi-regular basis.

At times, it can be difficult to allocate time for fixing old code. However, maintaining up-to-date code can be a crucial part of managing a website, especially when it comes to website security. When reviewing old code, things to look for include

• Depreciated code
• Options for streamlining
• Security holes

Replacing Depreciated Code

Over time, aspects of our code may become depreciated. For me, a more memorable piece of code that shouldn't be used is the <font> tag in HTML. For those unfamiliar, the <font> tag was used to indicate how text should be displayed (color, size, etc.). It was depreciated in favor of the styling options provided by CSS. It's pretty scary to see the tag still cropping up when reviewing someone else's code. At least it's not the <marquee> tag.

A more recent example is the use of the ereg_replace() function which was depreciated in PHP 5.3. It's recommended by the PHP manual to use something like preg_replace() instead. For example, the following code was found in a script I recently updated:

<?php
$total = ereg_replace('\$', '', $total);
?>


The code uses a regular expression to replace all occurrences of the dollar sign ($) with nothing. In the end, the $total variable would contain whatever value it had before without the dollar sign. To continue using the regular expression, the code just needs to be updated to the following:

<?php
$total = preg_replace('~\$~', '', $total);
?>


Note that preg_replace() requires a delimiter around the regular expression part (aka the pattern) and the forward slash (/) is typically used. The problem is that every time the delimiter character appears within the pattern, it needs to be escaped. To limit the pattern's complexity, a character which isn't used very often, like the tilde (~), can be substituted.

Also, there is a more efficient way than preg_replace() for the above example. So don't go changing those EREG calls just yet. At least wait until after the next section.

Streamlining Inefficient Code

Finding depreciated code probably isn't going to be as common; we're more likely to see inefficient code. The ereg/preg code above doesn't really need the power of regular expressions. The str_replace() function gives the same results.

<?php
$total = str_replace('$', '', $total);
?>


Although switching str_replace() is more efficient, it may not feel like much of an accomplishment. However, it's exciting to find those solutions that took several lines of code and replacing them with a built-in function that does the same thing. For example, let's say we have the following chunk of code:

<?php
$testArray = array(5, 10, 6);
$separator = '';
foreach($testArray as $currVal) {
print "$separator$currVal";
$separator = ', ';
}
?>


The code takes the array and displays the values as a comma-separated list. Well, the code to display the array could all be replaced with a single function:

<?php
$testArray = array(5, 10, 6);
print implode(', ', $testArray);
?>


The implode() function converts an array to a string and adds the indicated separator between each value.

Fixing Insecure Code

So far, the changes mentioned probably won't have much effect on our websites, at least in the short run. After all, the <font> tag still works just fine—as does the <marquee> tag I'm afraid. The code that really needs our attention is the parts which could lead to a website being compromised. Last week's post (Why PHP_SELF Should Be Avoided When Creating Website Links) discussed the dangers of using PHP_SELF within a website. Of course, there are many other security issues to watch for.

For example, a few years back, my website host had it set so quotes in POST and GET variables were escaped by default. Then it was announced that the default setting was going to be changed; quotes wouldn't be escaped anymore. With quotes not being escaped, user data could be utilized for SQL injections. Plus, visitors entering quotes in a form field for a valid reason (such as an apostrophe in their last name) might get an error when adding the information to the database. Now, the mysql_real_escape_string() function (for MySQL) is needed to help keep the database secure.

Conclusion

Now that we have some ideas of what to look for, it's time to get out there and clean up those old scripts. It'll improve the efficiency of our websites and increase security. As an extra bonus, updating our old code can be a great gauge to see how far we've advanced as developers.