On PHP

Essays, ,

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.

iPhone Disappointment

Asides, , ,

The process of buying the Apple iPhone was pretty easy. Glenda and I walked into a store in Daly City at about 8:30 PM and each ordered one, and walked out. No lines. The device is physically much more elegant and smaller than I expected, and the iTunes-integrated signup process was fairly smooth. However, it’s been hours now and still no activation, which means I have a very expensive paperweight, which is worse than not having it at all. Update: Approximately 16 hours after my inital setup, I now have a working phone. I was contemplating taking it back, but I’m glad I didn’t.

On WP Security

WordPress

Wincent Colaiuta has no problem throwing flames at WordPress, but doesn’t see fit to enable comments. (Apparently disabled to make Movable Type more secure.) His table-layout blog isn’t too notable but it got linked from Daring Fireball so a lot of people saw his article trying to draw the line between a routine point release and encouraging people to never use WordPress on the public internet. Here are a few points for thought in response:

  • The SQL problem in 2.2 requires both registration to be enabled (off by default) and the blog to be upgraded to 2.2. It is a serious problem but I’ve heard of fewer than 5 exploits from the flaw. Even if you assume there are 100 blogs for every one we heard about, that’s still an incredibly small percentage of the millions of WordPresses out there, especially considering, as Wincent points out, the problem has been in the public for a while now.
  • Getting people to upgrade web software is hard. We work as best we can with hosting companies, but a consideration is that it’s best to roll several security fixes into one release. It’s not responsible to do a release if we know of another problem, so sometimes there is a lag between an initial report and a final release, not to mention the testing required of a product used as much as WP.
  • Wincent digs up the server crack that modified the files of 2.1.1 for a few days. Ignoring the fact that it was a server issue and had nothing to do with WordPress the software, we actually had NO reported exploits of the problem. (Though I’m sure there are at least a handful out there with problems, it wasn’t enough to hit our radar.) Despite that we took a hit and publicized the issue as much as we could to get the word out.
  • Also about 2.1.1, the problem was found through someone proactively auditing the codebase.
  • Finally Wincent says of WP “[a]nd if you insist on installing it, then you need to watch the trac like a hawk.” You would think complete transparency of the problems (it was on our bug tracker and mailing list) would be a good thing, especially considering the software Wincent uses doesn’t have a bug tracker, and the only way to submit a bug is through a contact form.

We can and do review new code for problems, and pick the vast majority up before any releases. I think the real issue though is not that WP has bugs which are sometimes security related, which all software not written by djb does, but that the mechanisms for updating complex web software are a pain. Right now the best experiences are probably with folks like Media Temple or Dreamhost that have pretty foolproof one-click upgrades and are quick with updates.

Making notification better and upgrading more painless for people not lucky enough to be on a host like that are problems with some very clever minds on them, and I’m confident that we’ll have good progress toward each in the next major release of WP.

Finally, I suppose we could act more like our proprietary competitors and try to downplay or hide security issues instead of trumpeting them loudly in our blog, but I think the benefit of having people well-informed outweighs the PR lumps we take for doing the right thing. I truly believe talking about these things in the open is the best way to address them.

In some ways it’s a good problem to have. When a product is popular, not only does it have more eyes from security professionals on it, but any problems garner a level of attention which is not quite warranted by the frequency of the general event, like Angelina Jolie having a baby. There are certainly things intrinsic to coding that can make software more or less secure, but all things being equal the software with the most eyes on it, which usually means Open Source, will be the most robust in the long term.