PHP 4′s last gasp

PHP 4.4.8 was released today (3 January 2008)—three days after PHP 4 officially reached the end of its support life. For some strange reason, PHP releases are always made on a Thursday, so the release was delayed until today to avoid slipping it out on 27 December while everyone was still comatose during the Christmas and New Year holiday season. This version incorporates a handful of fixes for security issues and bugs, but adds no new features. Unless a major security issue emerges between now and the Beijing Olympics (8 August 2008), this will be the last ever version of PHP 4.

My reaction? About time, too. PHP 4 should have been abandoned a long time ago. The problem is that hosting companies moved to PHP 5 at a glacial pace. Even now, three and a half years after the release of PHP 5.0, only one in four PHP websites runs on PHP 5. In the early days, administrators blamed stability problems and memory leaks on shared hosting. Since I use a dedicated server, I have never come across such problems myself, but PHP 5.1 and 5.2 have added stability and performance improvements that should overcome any objections.

Perhaps a major contributory factor to the slow adoption of PHP 5 has been the memory of what happened when register_globals was turned off by default in 2002. Suddenly, scripts that had worked the day before ground to a halt. Turning off register_globals was done to plug a gaping security hole in PHP; but so many people relied on variables being created automatically from form fields and URL query strings that exasperated system administrators turned register_globals back on in spite of the security risk. This was, of course, the wrong solution. Instead of permitting insecure scripts, hosting companies should have shown their clients how to write secure scripts by using the $_POST and $_GET arrays.

There’s now a fear that switching to PHP 5 will suddenly break all scripts written to PHP 4 standards. The answer is that—in the vast majority of cases—it won’t. The only area of major incompatibility between PHP 4 and PHP 5 lies in the object-oriented model. Even so, there should be no problems continuing to run old OOP scripts as long as you don’t try to mix them with ones written using the new PHP syntax. I have a large website written using PHP 4 classes, which I moved onto my PHP 5 server back in August 2004. It ran perfectly with no changes, and is still running happily.

If you’ve no idea what an OOP script looks like, you probably have nothing to worry about anyway. Object-oriented code tends to be used only by advanced developers. Those most at risk are cut and paste merchants who use code in their web pages without knowing how it works. As long as you get code from a good source, you don’t need to understand it in minute detail, but you do need to know what it’s for, and how it fits in with the rest of the page. If you’re worried that you might have PHP OOP code in your pages without realizing it, look for the -> operator. A typical line of OOP code looks like this:

$result = $db->query($sql);

The key to successful migration to PHP 5 is well-written code. If you have been using best practices, such as writing scripts to work with register_globals off, you should have no worries upgrading to PHP 5. Other things to check:

  • Use $_SESSION instead of session_register().
  • Use $_POST, $_GET, and the other superglobals instead of the deprecated long versions, such as $HTTP_POST_VARS. Many PHP 5 servers don’t support the long versions; and even if they do, you should never mix them with the new superglobal arrays. When created alongside each other, they are treated separately, and changing the value of one has no effect on the other.
  • Make sure that you pass arrays as arguments to functions that expect an array. PHP 4 won’t complain if you pass a string instead. PHP 5 isn’t so obliging.

Migrating to PHP 5 is not only nothing to worry about, it offers a lot of advantages, the most important of which is that PHP 5 remains under development. Security improvements are constantly being made. There are also lots of new features that make coding simpler and more pleasurable. For example, writing to an external file is simply a question of using file_put_contents(); no need to mess around with file handles unless you need to read the file at the same time. PHP 5.2 also introduces a very useful set of filters for sanitizing user input. And working with XML is a piece of cake with the aptly named SimpleXML.

If your hosting company hasn’t yet announced plans to migrate to PHP 5, start pressing for it to do so now. Also, get an assurance that regular updates will be made to the version on your server. It’s no good your hosting company moving to, say, PHP 5.1.6, because the PHP 5.1 series is already dead. As the PHP “museum” page warns, older releases are listed for archaeological purposes only, and they are no longer supported.

While checking on your hosting company’s offering, it’s also worth checking which version of MySQL is being offered. Few people seem to realize that all support for MySQL 3.23 ended more than a year ago. Active support for MySQL 4.0 and 4.1 also ended in 2006 (extended support continues until the end of 2008 for 4.0, and until the end of 2009 for 4.1). With MySQL 5.1 due out any time soon, you should be insisting on a minimum of MySQL 5.0. At a push, 4.1 will do.

This isn’t advocating the latest versions just for the sake of being up-to-date or trendy. Security on the web is extremely important, and it’s unrealistic to expect the developers of PHP and MySQL to keep patching up older versions. The PHP development team is working hard on PHP 6, but progress has been delayed by the constant distraction of maintaining two major versions at the same time as creating the next one. It also presents a problem for authors like myself. When I wrote PHP Solutions, I wanted to use PHP 5 code throughout, but I realized that the majority of readers would still be stuck with PHP 4. As a result, I had to write two versions of much of the code. With PHP 4 now officially no longer supported, there’s no reason to write books and tutorials that are hamstrung by the need to provide workarounds. So, if your hosting company doesn’t upgrade, you’ll find support for your system more and more difficult to come by.

This entry was posted in PHP. Bookmark the permalink.

3 Responses to PHP 4′s last gasp

  1. Justin Liou says:

    I’m trying to set up a local server but the latest PHP 5.2.5 doesn’t work with the latest Apache 2.2.6 . Step 7 under “Installing PHP on Windows” in CH. 3 does not show. http://localhost/test.php does work but it only shows the code. Should try and fix it or just use a remote server for now?

  2. Justin Liou says:

    Actually, when I connect it works on IE but NOT Firefox

  3. Justin Liou says:

    Another update. It’s fine now. For some odd reason it just started working but the Apache icon doesn’t display in the taskbar.