Tag Archives: php4


PHP.net has announced that they will stop development of PHP4 at the end of this year, and end security updates on 2008-08. (In 2007, their site still doesn’t have obvious permalinks. They do have a RSS 1.0 feed though, remember those?)

PHP 4.0 was release in May of 2000, by 2004 when the first version of PHP 5.0 was released, PHP 4 had achieved complete dominance and was completely ubiquitous in both script and hosting support.

Fast forward 3 more years and PHP 5 has been, from an adoption point of view, a complete flop. Most estimates place it in the single-digit percentages or at best the low teens, mostly gassed by marginal frameworks. Even hosted PHP-powered services who have no shared host compatibility concerns like 30boxes, Digg, Flickr, and WordPress.com, have been slow to move and when they do it will probably be because of speed or security, not features.

Some app makers felt sorry for PHP 5 and decided to create the world’s ugliest advocacy site and turn their apps in to protest pieces at the expense of their users. (Hat tip: Mark J.) They say “Web hosts cannot upgrade their servers to PHP 5 without making it impossible for their users to run PHP 4-targeted web apps” ignoring the fact that there isn’t a released PHP app today that isn’t PHP 5-compatible and recent upgrade issues have been caused by PHP itself in point releases. (See WP#3354.) It’s easy to always promote the newest thing, but why, and is it for us or our users?

Now the PHP core team seems to have decided that the boost their failing product needs is to kill off their successful one instead of asking the hard questions: What was it that made PHP 4 so successful? What are we doing to emphasize those strengths? Why wasn’t PHP 5 compelling to that same audience? Are the things we’re doing in PHP 6 crucial to our core audience or simply “good” language problems to solve? Will they drive adoption? How can we avoid releasing (another) PCjr?

I wonder if PHP 5+ should be called something other than PHP. A unique name would have allowed the effort to stand on its own, and not imply something that’s an upgrade from what came before when in many cases it’s just different, not better, from an end-user perspective. Continue to maintain PHP 4 as like a PHP-lite. Make it harder, better, faster, stronger.

For all the noise though, this isn’t a big deal. It’s easy to forget that PHP 4 hasn’t had any real innovation in the past 3 years while at the same time apps and services built on top of it have created some of the richest and most compelling user experiences the web has seen. (Née Web 2.0.) None of the most requested features for WordPress would be any easier (or harder) if they were written for PHP 4 or 5 or Python. They’d just be different. The hard part usually has little to do with the underlying server-side language.

Someday on our mailing lists I hope half the words wasted pontificating on “language version wars,” which are even duller than language wars, go toward design, copywriting, information, performance — the things that truly matter.