How to Kill PHP 4?

That’s the question being discussed among some prominent Drupal and WordPress developers right now. You see, the problem isn’t that they don’t love PHP, Drupal and WordPress are two of the most popular PHP applications. And both of them use PHP 4. (Null is Love is running WordPress with PHP 4.3)

Drupal and WordPress logos

The problem, they say, is that web hosting companies are reluctant to switch to new-and-improved, object-oriented PHP 5. (PHP 5 has only 17% adoption after almost 3 years.) Therefore the developers can’t roll out versions of their apps which require PHP 5. And since major applications don’t require it, the web hosting companies don’t feel any pressure to switch, especially since both PHP 4 and 5 are being supported by bug and security fixes. For them, software upgrades equals support headaches which equals time and money, so they need a compelling motivation. It’s become a chicken-and-egg problem (a.k.a. deadlock) and these PHP developers are looking for a way out.

So what to do?

Nick Lewis started the discussion by asserting that major developers should draw a line in the sand and require PHP 5. Dries Buytaert responded that the PHP team needs to “make PHP5 attractive to ISPs and end-users, and focus less on application developers”. Larry Garfield agreed with them both and added that the PHP team should stop providing PHP 4 updates. Ryan Boren disagreed, saying the first step is for the PHP team to set an end-of-life date for PHP 4. Personally, I like Boren’s planned obsolescence approach, but I can also sympathize with the impatience everyone’s feeling. While it won’t solve it immediately, as soon as that EOL countdown starts developers and web hosts will have a future path, a way out of the quagmire, for which they can start planning.

It is an interesting case study with lessons broader than PHP. All web technologies face upgrade and adoption barriers. I recently struck out on getting a client’s web hosts to upgrade from Apache 2.0 to 2.2 because 1.3 is where most support exists. When should developers and web hosts stop supporting old versions of MySQL? When can designers presume all browsers will support CSS 2.1 (and eventually CSS 3)? Will Ruby on Rails face adoption issues when version 2 is released and all those friendly deprecation warnings become full-fledged errors? And I’ve often wondered, what’s the use in having XHTML strict if there’s no incentive to ditch XHTML transitional? PHP’s struggles may offer larger insights everyone can learn from.

You can read the original discussion and follow along as it develops:

Bookmark and Share

One Response to “How to Kill PHP 4?”

  1. Null is Love » Blog Archive » PHP 4 Deathwatch: February 5, 2008 Says:

    [...] the PHP developer community’s desire to kill off PHP 4 and why that’s not so simple. (“How to Kill PHP 4?”) PHP 5 has been out for years and PHP 6 is on its way. My view back then was that the best approach [...]

Leave a Reply