PHP 5.2 and Earilier (versions < 5.3) Code Problems
As PHP matures, and new versions are released, one thing I’ve noticed is consistent: deprecated language constructs, built-in PHP funtions, and various favourite code snippets throw warnings– or worse– errors, even the so-called production environment. It’s beyond the purpose of this article to pick apart which portions of what versions of PHP are going to cause error, so don’t expect to find that sort of dialogue here.
Use the Regular Expression presented below to repair PHP code, where ereg() is deprecated. The expression, intended for a text editor, or text processing tool, replaces the deprecated code with a perfectly compatible PHP function, preg_match_all() which– unlike eregi()— is compatible with PHP 5.3, and shows no likelihood of being deprecated any time soon.
The purpose of this article is to share one possible solution to problems which might arise, if and when the reader makes his or her jump from an earlier version of PHP to PHP 5.3 (or newer). On the one hand, I’ve been fortunate to establish a habit writing code to be forward compatible. As this article demonstrates, however, not all of my code has stood the test of forward compatibility. I advise the reader, take heed: whenever a new version of PHP is released, be sure to install it on your development server, and get acquainted with writing code which does not throw any sort of error, warning, or notice. Maintain that ideal, and you’ll find a greater likelihood that your code will stand the test of time. If you don’t believe me that this is both true, and important, then follow through with the following steps to prove it for yourself:
Locate the latest stable release of PHP for your development server platform, as available at www.php.net
Download, and install the version of PHP you’ve just located, and verify through phpinfo() that your server is running the latest version, according to your installation
Configure PHP to throw errors and notices, on anything and everything. As of writing, that configuration should look something like the following: @≅php.ini:500 > 300 | < 600 (i.e. locate php.ini line somewhere between lines 300 and 600†)
error_reporting = E_ALL | E_STRICT
Go about your business, writing code, and testing it on the development server, as configured (i.e. on the previous line, here)
If lady luck is on your side, or you’ve never authored any bit of PHP which does not conform to the latest PHP coding standards, then you’ll see no problems.
Kills 99.9% of Germs on Contact
I’ve implemented the following regular expression, successfully, in thousands of files. However, while authoring this article, I’ve realized my regex stinks! Ha! Well, maybe it doesn’t smell that bad (can you smell it all the way over there?), but it’s not perfect. I realized, the thing is going to break if the target string contains a comma, a single or double-quote mark. A savvy regex engineer would recognize it straight away. I should have seen it too. Well– I guess I did see it– only I’d already, essentially, authored this post (i.e. i had to add this part, to explain my foul, just before hitting ‘publish’).
PHP uses– rather– used to use different functions for testing stings against a regular expression match. I’m thinking of one function in particular, but it’s really two separate functions: ereg, and eregi— the case-sensitive, and case-insensitive versions of essentially the same function– which have been deprecated for several versions of PHP; which now throw a “deprecated code warning”, since PHP 5.3, if the development server is set, as described above.
Use the following regular expression to repair deprecated code, where the following causes the php compiler/ interpreter to throw an error:
eregi("any text string", $containerSymbol)
DO NOT APPLY THIS SCRIPT TO MULTIPLE FILES, AS IT IS NOT 100% ERROR FREE! Follow my logic, explained below, to understand my thinking in building the expression as shown. At section #2, at least, the script will fail, if it encounters a single or double-quote, or a comma, in the subject-string of the PHP eregi syntax. Indeed, it’s confusing to speak of applying a regular expression to a function which is itself a regular expression!
Please contribute your suggestions for improving the following logic: My logic follows: “1.) Let the regex allow for a string enclosed in either single or double quotes (as illustrated in the first atom). 2.) Match anything-but the closing quote [or a comma]. 3.) Match the closing quote. 4.) Match the necessary comma, and allow for extra white-space (i.e. according to the PHP syntax for eregi, where a comma separates the target string (i.e. the “subject”), from the test string [i.e. the search pattern– usually a PHP variable]; the comma separating the first from the second argument of the ereg syntax). 5.) allow for the pattern to be a constant, such that it might not begin with a “dollar sign”, as most php variables would. 6.) use the same logic applied for matching the target string, to match the target php Variable. (Granted, it’s overkill for a target which is probably going to be one word, but i didn’t experience any problems because of the broad range of possible matches.
Go Forth and Die
Use a text editor which complies with the syntax presented here to perform the task. Ideally, use a tool with a “find in files” function which supports regular expressions as well, for “find in files”. The tool i used is designed specifically for manipulating text, on a large scale, as described here. TextCrawler, by Digital Volcano is that tool. In fact, I’m authoring a page specifically about TextCrawler, which raves about the incredibly efficient power it packs for jobs just like this regular expression, search and replace task for PHP eregi() syntax to preg_match_all() syntax.
Using TextCrawler by Digital Volcano, I was able to apply the search and replace function to tens of thousands of files, all at once, and I have yet to encounter any problems resulting from scripted function, as described above. DO NOT APPLY THIS SCRIPT TO MULTIPLE FILES, AS IT IS NOT 100% ERROR FREE!
Spacehog
In the meantime… I’ll do what I can to improve this expression, to improve the chances it will not break, no matter what text its fed. For now, it should be effective for most needs. I don’t recommend, however, applying this expression to thousands of files, as I did, for you may be left with a ton of garbage, and quite irritated with me as well. In fact, forget anything I said about using a “find in files” function. I recommend applying this to one file at a time, to ensure the expression isn’t doing anything unexpected. Regardless, I’m confident someone is going to find this to be a convenient, plug-and-play sort of very easy, quick fix for broken code. As always, your feedback is encouraged.
†This is not precisely such an example, as I’ve tried to indicate a range of lines, however, it is common convention that line numbers are indicated for a given file, as follows: file.name:123 , where file is the name, name is the extension, and 123 is the line-number indicated by its separation from the filename, and extension, by the ‘:’ [colon symbol]. For example, many text editors will accept that very syntax, and place the cursor at the line indicated, if sent such a command via the “run” dialogue, or via command line, as in "C:\Program Files\Edit Plus 3\editplus.exe" "Z:\File\Path\file.name:123", where EditPlus, in this case, will open the file to line 123.
Leave a Reply