I’ve been meaning to write this post nearly a month now, on the heels of WordPress 3.0’s release and preparing for an inevitable future discussion of when we should drop PHP 4 support. 0 And then current events give you the hook you need to sit down and do it.
A peculiar bug sent over the mailing list for WordPress support forum moderators piqued my interest. There was an incompatibility with WordPress 3.0 and Earthlink hosting, with no known solution. Until this point I wasn’t even aware Earthlink did web hosting. I’ve enjoyed communicating with MediaTemple, GoDaddy, Network Solutions and Dreamhost on Twitter, but I couldn’t find Earthlink, so I picked up the phone and simply called their support line.
I explained who I was, and someone helpfully filed my contact information in a ticket reported by an Earthlink customer. I wasn’t expecting a response, at least not a speedy one, but the next day I received an email from Earthlink.
I give them a ton of credit for this, because the initial email I received included everything they knew, along with full access to a test server. Since the email also included the fatal error from the log, I pulled up the file and line, and realized the problem immediately.
Here’s where Earthlink stops receiving credit: they were running PHP 5.0.5, released in 2005. (I may agree with WordPress supporting old versions of PHP, but that doesn’t mean I support them being used.) Apparently, there was a change in 4.4 and 5.0.5, fixed in 5.1.0, that prevented you from passing by reference into one function the return value of another function, and requiring you to assign it to a variable first.
A few things to emphasize. This affects very few installs. Our PHP 4 usage is very low as of late, and given the few reports of the issue and that they can all be tied back to Earthlink, 5.0.5 is not seen in the wild often either. So while the fix is included in WordPress 3.0.1, there is nothing we have seen that would make me think we should speed up the 3.0.1 release, which generally comes about a month after the initial release. 0
While we do PHP 4 compatibility testing, as of late it is limited, which has valid reasoning but is also a valid problem. Even testing under our minimum requirements, 4.3.0, would not have caught this bug, which was only in 4.4 and 5.0.5.
The day I called Earthlink, I also spent some time browsing old mailing list threads, and by chance I found the discussion on the Drupal development list that started the GoPHP5 initiative. Drupal was pretty quick to announce that the PHP 5.2 requirement would apply to Drupal 7.
Matt and others rightfully expressed that the original approach was flawed. We should not become “a protest piece at the expense of our users,” Mark Jaquith wrote at the time. Matt called it the “world’s ugliest advocacy site,” which holds true today. What doesn’t hold true today is the lack of penetration by PHP 5, but what did GoPHP5 really accomplish?
Some might say GoPHP5 was ahead of its time, or caused web hosts to adopt PHP 5.2. Being ahead of one’s time is not always a good thing. Drupal 7 is due out this year. In hindsight, whether it was an educated guess or an arbitrary future version, it ended up timing well with the market’s adoption of PHP 5. Joomla 1.6 (in beta) will also require PHP 5. And then you have WordPress, always derided for their “rejection” of PHP 5 and desire to support PHP 4, reacting to the market reality, instead of choosing politics over users.
Three years ago, WordPress sat out the round. In hindsight it appears to be an excellent choice, rooted in finding the right time to adopt instead of treating it as an idealistic race. Luckily, neither Joomla nor Drupal became a protest piece three years ago. The movement was all bark and no bite.
It’s tough enough to get someone to stop using IE6 or IE7. You can show them two browsers side by side, and have the site glow in a standards-compliant browser and cry in one of them, and it is still a tough sell for those who think the blue E is “the Internet explorer.” 0 Those who utilize a shared host to run distributed software are certainly more technical, but they don’t care about PHP 4 versus 5, they care that it works. Deliberately breaking it when market penetration of PHP 5 was less than 20 percent wasn’t exactly the correct solution to the problem.
Fast forward three years, and PHP 5 market penetration is no longer an issue. The WordPress developers long ago agreed that the indicator for dropping PHP 4 support is when less than 10 percent of WordPress installs run PHP 4.
But it is not about features, or language constructs, or needing to occasionally cater to PHP 4 syntaxes or idiosyncrasies (this Earthlink issue wasn’t even a PHP 4 bug). None of that has much of a bearing on any decision to drop PHP 4 support because of how we approach it. If it is too costly to develop a feature for PHP 4, then we offer the feature as a progressive enhancement for PHP 5 installs. 0 We’re a system that gets extended in every which direction. Dropping PHP 4 won’t change us overnight, nor would it change our development philosophy.
For us, it’s about testing coverage. If we have finally reached the point where too few users are running and testing WordPress on PHP 4 and early versions of PHP 5 for us to be able to make an informed guarantee of their compatibility, then it’s time to move on.