On PHP, Redux

Earlier today, Aaron Jorbin showed me an interesting conversation on the Portland PHP mailing list about PHP 5.2 and WordPress. I’ve previously written about this subject around the time we announced we were moving the minimum requirements to PHP 5.2 in WordPress 3.2, but there were a lot of questions, concerns, and statements in this thread that deserved a reply, so I joined up to offer one.

I was really happy with how my response turned out. I think it very effectively laid our thoughts and strategies on the table. It was pretty long (I jokingly coined a new unit of measurement in the process) and I believe it was an informative read, so I wanted to re-post it here. I’ve quoted previous emails from the thread throughout my reply, which has been lightly edited —

***

The problem I have is the holdovers who absolutely refuse, like WordPress up until recently. Most projects that refused to support PHP 5 ultimately have been replaced with proejcts that do; it’s the large ones like WordPress that are of deep concern to the community because they hold back PHP from further growth.

See, that’s not true at all. We’re not slow to adopt PHP5. Hosts are. MediaTemple, for example, is still PHP4 by default on their grid service. That’s insane, and we don’t like it at all, but there’s only so much we can do about it. (That said, hat tip to Dreamhost, because they shut down the PHP4 option when it went EOL, and a few months ago they pushed every remaining PHP4 account to PHP5.)

A year ago, more than a few million blogs were still being powered by PHP4. WordPress refused three years ago (when the GoPHP5 movement started) to make a political statement by pushing a product that had less than 20% adoption. About a year ago, WordPress told its community that when PHP4 usage dropped below 10 percent of active blogs, we would abandon it. But we refuse to abandon our users lightly.

My understanding is that WordPress wrote their OWN JSON parser to avoid having to make people upgrade to PHP 5.2; that’s just asinine.

By putting for an extra effort to maintain PHP 4.3 compatibility, WordPress is letting their user’s intertia keep them on the platform.

I’ll address both of these at once. As said previously, we refuse to make a political statement and abandon our lowest common denominator for our users. Only 4 percent of WordPress installs are running critically insecure versions precisely because WordPress is so easy to use and so easy to update. (Drupal is at 69 percent.) If we drop PHP4 too early, users just won’t upgrade. That’s bad for everyone. End users do not care what version of PHP they are running, period.

We do not put in extra effort to maintain PHP4 compatibility. The last bug related to PHP4 compatibility was actually a core PHP bug that affected 5.0.5 as well as 4.4.0. Beyond that, the only effort is to ensure syntax is proper. With regards to feature development, if we have to go out of our way to support PHP4, we don’t bother and instead offer the feature as a progressive enhancement for PHP5.

Case in point, when we implemented oEmbed in WordPress 2.9, we had to make a choice. We request that the oEmbed provider returns JSON, but they may also return XML. At the time, many sites still weren’t running at least PHP 5.2.0, so we didn’t always reliably have JSON or SimpleXML.

So, here’s what we did. We included the official Services_JSON PEAR library, which allowed us to implement JSON for < 5.2. We did not write our own parser. (That would indeed be asinine.) But importantly, if we're given XML and we don't have SimpleXML around to assist, we don't bother and return false. Another example is timezone support. We use the PHP DateTime library if available. If not, then they have to handle their own settings, timezone offsets, DST adjustments, and such. We don’t make an attempt for PHP4. These are but two examples of the progressive enhancement.

WordPress has over 50 million blogs, and VC daddies with 44m+ invested in them. It’s all well and good to want to keep using the latest and greatest, who in their right mind is going to say: “lets dump more than half of our audience because their webhosts are slow to upgrade.”

The second part is very true, though it’s not more than half anymore, and hasn’t been for a year or two. I do want to point out, however, that in the first part you are referring to Automattic, the company behind WordPress.com (the hosted service). They do invest heavily (in terms of time, servers, etc.) in the open source project, which is WordPress.org. But half of the core team members do not work for Automattic (including myself), and three of those that do are 70-100% dedicated to the project, not to for-profit Automattic work.

By supporting PHP4, WordPress perpetuates PHP5 [sic, I assume they meant PHP4]. Make WordPress require PHP 5 and the hosting services will upgrade.

It comes down to making political statements. No, it won’t, not historically. It will now, because WordPress is becoming more and more ubiquitous, and there are but few hosts that only have PHP4. Most just need to flip the default to 5. The GoPHP5 movement didn’t do anything beyond being before its time. Being before ones time isn’t always a good thing. More on that in a moment.

I know nothing about WordPress’s development, but I imagine that they probably were going to support PHP5 only with WordPress version 3, and then something forced them to abandon this strategy. That’s pure speculation on my part, however the length of time between 2 and 3, and the major version number change implies it.

We increment version numbers on a simple base 10 decimal system. 2.8, 2.9, 3.0, 3.1. All major versions. (Our minor maintenance releases are 2.9.1, 2.9.2, 3.0.1, etc.) About a year ago, we made a determination that when usage of PHP4 dropped to 10 percent, we will drop PHP4 support. Keep in mind that 10 percent is still a few million users for us, which is not an easy thing to do.

We looked at the statistics in July and noticed that our 5.2+ usage was at about 88 percent. The PHP4 number is below 10 percent, though not by much as PHP 5.0 and 5.1 doesn’t have much in terms of share. (And thankfully so, as they’re pretty buggy.) About a week later, we announced that we were dropping support for PHP4 and MySQL4 with WordPress 3.2, which will be released sometime in the second quarter of 2011. (Yay.)

Let’s study that a bit further for a moment, and see how other projects are handling this. We have more users on PHP4 (and even just 4.4) than we have on PHP 5.3. Yet, the day before we announced our minimum version bump (which we decided in our public developers meeting the week before), PHP released 5.2.14 and announced they were stopping non-security maintenance for PHP 5.2. You should have heard Marco Tabini of php|architect blast this when he spoke at WordCamp Mid-Atlantic a few weeks ago. It’s yanking the rug out from under everyone just as it is finally ubiquitous. If you’re going to fault the applications, you need to fault core PHP right there with the hosting companies. (See Matt’s post, linked below.)

Meanwhile, only about 3 percent of WordPress sites are on PHP 5.3. Suddenly more users are going to be on PHP 5.2, and it’s going to strain it further. It isn’t just us, either. Drupal and Joomla, even though both were part of the GoPHP5 movement three years ago, are only now dropping PHP4, too. Hypocritical to attack us, but it happens anyway.

Dries announced in 2007 that Drupal 7 would be PHP 5.2. This was in response to GoPHP5, which was born on the Drupal mailing list. It apparently made everyone there complacent, but you’ll find now that Drupal 7 still isn’t out yet. Meanwhile, WordPress waits and tries to react to market usage instead of making a political statement with an arbitrary line in the sand, and hypocritically, we get derided or laughed at. Also, Joomla 1.6, still in beta, is also the first release of theirs to drop PHP 4. They’re going to 5.2 (I’ve seen reports of 5.2.4).

A note, we’re closely following both Drupal 7 and Joomla 1.6 and jumping to MySQL 5.0.x, again forcing the hands of nearly 5 percent of our users. Point is, we’re taking a different approach, yet we end up in the exact same boat, same result, same timeline.

With that, I’ll also reference a post I made on my blog just before we officially announced we were going to PHP5. It further explains some of the history and our philosophies here, why testing coverage is a driving factor, and the like. You should also read Matt’s post from three years ago. The discussions in the comments on both posts are particularly informative.

Thanks for your time. It’s been fun, and I’m sorry if it was tl;dr.