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.

Published by

Andrew Nacin

Lead developer of WordPress, living in Washington, D.C. Follow me on Twitter.

9 thoughts on “On PHP, Redux”

  1. I had a *very* similar discussion with someone today and made many of the same points. I think it’s absurd for core PHP to drop 5.2.x support now.. it’s a big FU to many of the communities that could be our allies but have to lag behind due to things (hosts, 3rd party code, etc) outside their control.

    Disclosure: Marco Tabini is one of my partners & I actively work for/with php|architect.

    1. Keith, what is absurd is to be demagogic while claiming that we drop support for 5.2. We do not. It is in maintain mode (security&critical bug fixes only). However its end of life is not too far.

      How is it different to what has been done with 4.1/2/3? or 5.0/1? It is not different, except that we explicitly say it now instead of the day when it will not supported anymore (or not saying anything and just let it die).

      More than three years is somehow a lot of time for a small group of developers. Especially while we have hard time to get support for the QA parts of our work (remember our last discussions about you testing releases using your apps?).

      It is also stupid to ignore the fact that most distributions will support 5.2.x for a couple of more years (debian, fc, bsd) and even more for rhel&similar. To do not mention the full compability between 5.2 and 5.3 is somehow disturbing as well.

      All in all, this is a no event. Not a single end users (as users using your apps) will notice that. But you have noticed it and that’s a good thing, as you are aware of this change and can plan nicely what to use for your next project or step.

      1. How is it different to what has been done with 4.1/2/3? or 5.0/1? It is not different, except that we explicitly say it now instead of the day when it will not supported anymore (or not saying anything and just let it die).

        For the 4.x line, there was a year+ notice. This time, maintenance mode was announced day of.

        Especially while we have hard time to get support for the QA parts of our work (remember our last discussions about you testing releases using your apps?).

        When you don’t communicate intentions, we don’t know of the importance. That conversation was approximately one week before 5.2 went into maintenance.. once again, without notice.

        It is also stupid to ignore the fact that most distributions will support 5.2.x for a couple of more years (debian, fc, bsd) and even more for rhel&similar.

        include != support

        I believe it is foolish to end support for a product that 85%+ of your users are currently using.

        To do not mention the full compability between 5.2 and 5.3 is somehow disturbing as well.

        Except for E_Deprecated warnings that is. On first releases of 5.3 many of the applications were caught flatfooted. I personally saw numerous threads of “what are these deprecation errors!?” responded to with “your PHP install is broken. reinstall it.”

        But you have noticed it and that’s a good thing, as you are aware of this change and can plan nicely what to use for your next project or step.

        Our target market is not people who build the software but people who use it. And since 90% of the web2project userbase is on 5.2, we can’t even look at 5.3 yet.

        1. For the 4.x line, there was a year+ notice. This time, maintenance mode was announced day of.

          And how is it different here? It is still supported. You seem to misunderstand the idea behind maintenance modes.

          include != support
          I believe it is foolish to end support for a product that 85%+ of your users are currently using.

          No, I said and meant support. They do support it and will backport much more than only security fixes. They do that since years and will continue to do that.

          Except for E_Deprecated warnings that is.

          Sorry, it is foolish to argue about developments warnings when we discuss about what your end users use in production.

          Our target market is not people who build the software but people who use it. And since 90% of the web2project userbase is on 5.2, we can’t even look at 5.3 yet.

          Ooch, seems like web2project has a nice roadmap then.

  2. “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 […]”

    Yet MT is one of the four shared-hosting providers wp.org recommends, while really modern providers like, for example, WebFaction are ignored. (I have an account with them just for testing stuff; they are on 5.2.11.)

    That’s a problem, and it also makes WP a bit responsible for the slow take-up of PHP5 in some parts of the web.

    1. Hey TJ –

      Thanks for stopping by! That’s great news. I couldn’t find that post and I had missed the announcement. I’ll update the post. Any news on MySQL?

      Andrew

      1. Thanks! All new (gs) Grid-Service accounts are provisioned with MySQL 5.1.26. Older accounts on some of the initial clusters still have MySQL 4.1.25 however we provide the option to upgrade. Customers that request an upgrade have the option to try our beta upgrade tool from within the AccountCenter.

Comments are closed.