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.
Well, not quite. The fix was obvious, but the bug was not. I consulted with Peter Westwood and we were able to locate two seemingly relevant PHP bugs and a note in the PHP 5.1.0 changelog. 0
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.
And that leads me to this post’s title: On PHP. It’s the title of a post Matt Mullenweg wrote three years ago, spurred by the GoPHP5 movement.
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.
Notes:
Sadly enough, one site I have on a particular host just gave me the option of upgrading to PHP5 a few months ago. The only reason I had even realized it was still on 4 was because I had a big, honkin’ error when I had uploaded one of my own plugins.
Backwards-compatibility can be good as long as it’s not at the expense of everyone else. I like the approach being taken so far.
As for footnote #3, I agree. I think I’ve gotten fewer WP upgrade support questions than any previous release.
Thank you Andrew! You are fantastic!!
I am the one that started the ticket at Earthlink.
As you can see, on my blog, the fix works š
Earthlink offers WordPress 2.0 as an automatic install.
They need to upgrade to 3.0 and PHP 5.2
It is a giant giant company. One of the oldest. It may be why they are slower to move.
My WP installations have all been manual on their servers. I guess people use their automatic install of WP 2.0 – but I am in music, photography etc and require all the new tools.
I installed a 2nd database that will be for my photography portfolio. But so far, I get a white screen after I activate the Widescreen theme. I get to the dashboard, after installing, and into appearances/themes (that might be the only other page I can get to outside of the dash – others lead to white screens) and can activate Widescreen there but it only leads to a white screen.
I am gonna call earthlink now and ask them “when are you gonna upgrade to 5.2 PHP”??
In the meanwhile…if anyone wants to help getting the multisite function to work…
I’m stuck
2.0 was a Long Term Support branch, maintained for a few years (up to 2.0.11, last released in 2007, and supported until 2009). So that might explain why Earthlink offers that. I’ll send a note to my new contact over there and see what’s going on there.
With regards to your white screen, I’d need to know the fatal error that is being masked in order to help. You should try the support forums; they can lead you in the right direction by showing you how to reveal the error, and then fix it. And if it’s a bug in WordPress, the awesome moderators there will make sure we hear about it.
I am having the same problem with Widescreen, installed at Earthlink. It is quite frustrating. (Naturally it is for a “quickie” job that was supposed to be no trouble.) The errors, if you are interested, are:
And Andrew, saw you at WordCamp New York. You were great. Thanks.
To continue: I don’t think it is a WordPress bug but is caused by an admin function added by Graph Paper Press, the authors of Widescreen.
RecursiveArrayIterator is, I think, PHP 5.3. Earthlink is probably still running 5.0.5, I think, and I somehow doubt they’ll jump all the way to 5.3.x unfortunately.
Best to contact GraphPaperPress and let them know they are using a language construct that is only available on about 5 percent of all WordPress sites.
This is the answer I received from graphpaper press
It’s [RecursiveArrayIterator] actually from PHP 5.1. All the hosts I have seen use PHP 5.2+ so this was not a problem and hence we used the term PHP5. This is a unique case. If you don’t have an option to upgrade then the theme might not work properly even if we commented those functions. Those functions are needed for the theme options to work 100% correctly. Please do see if your hosting can upgrade to 5.1 or 5.2 if not 5.3.
I’m coming in a bit late on this (sorry Daniel) but to clarify, RecursiveArrayIterator was introduced in PHP 5.1, so EarthLink users on PHP 5.0.5 will not be able to activate our themes without triggering a Fatal Error. For as long as I can remember we’ve told users that they need to run PHP5 (not specifying the version number; so few users on PHP5 reported any errors), so I’ll make sure that we immediately change all of our instructions to say PHP5.1+. Thanks for this post, Andrew.
Regardless of what you want to say with your article, and regardless that this is years over, a switch to PHP 5.2 can make sense generally.
But for the wordpress codebase, I think you should calculate about 6 month with 3 developers 2 full days a week to make a proper migration of the codebase. So this is not something trivial, if you put histories dust aside.
Personally, I think the “protest piece” line is silly. The GoPHP5 effort was about broadcasting intent and to not catch anyone off guard which often happens with major updates.
Drupal 7 was always known to be “years” away. The earliest possible date they guessimated was fall 2009. Realistically, the PHP5 penetration numbers haven’t changed much in the last year – mostly 5.3 replacing 5.1.6 and 5.2 – so they’re roughly on track.
Joomla… well, no one knows what they’re doing, not even them, so I don’t attribute anything there. š
WordPress community didn’t “sit out the round”, Matt fully engaged and called PHP5 a “flop”. If the WP community had said “3.0 will be php5 only”, they’d be in the same boat as Drupal. Instead, they made a stand that allowed and even encouraged hosting companies to stay with ancient versions of PHP known to have security vulnerabilities.
From that, you can also *theorize* that ignoring the PHP community and doing your own thing has limited how many and which of the best practices and ideas have crossed over between the communities. I’m not saying that any of the blogging/CMS platforms do it any better, just that both sides are missing out on lessons learned.. and repeating each others’ mistakes as if they’re all new.
For example, when I reviewed Aaron’s book, I learned about the WP hook system and implemented something similar in web2project. It’s not implemented remotely the same way, but the same concepts are applied and it’s already coming in handy. Both sides can learn. š
And I’m disappointed that you’re presenting the month after I’m leaving. š
Agreed that they haven’t changed much from 4 to 5. The usage numbers we’re seeing with WordPress installs, though, show very little 5.3 in the wild. There’s currently more WP installs running on 4.4 and 5.1 than 5.3. The PHP5 penetration numbers have shifted, I imagine, from 5.0 and 5.1 to 5.2, which is great for Drupal, because that’s what they were aiming for, and great for WordPress, because we’d want to jump right to 5.2 as well.
It looks like we’re getting ready to announce EOL for PHP 4. I expect such a decision and announcement would come this Thursday. Here’s the post where we’re talking about it. In that post, I also quote our PHP version stats:[ref]There’s also exactly one installation reporting PHP 6.0. The more you know.[/ref]
4.3 ā 1.3%
4.4 ā 6.3%
5.0 ā 0.1%
5.1 ā 3.5%
5.2 ā 85.4%
5.3 ā 3.4%
Okay, mea culpa. I imagine you may have gotten that from Aaron, who pointed out the exact same thing to me, but I failed to correct it. I didn’t characterize that right. WordPress sat out by refusing to commit to the effort, but yes, Matt and others certainly didn’t do it quietly.
Fair statement. I could defend WordPress’ years-old support of an EOL PHP 4 — it took until 5.2 and three years after that for it to become good, stable, and well-used — but there’s little defending it now. I constructed an argument here, defending the past, and making way for the future, but I absolutely considered that I could be wrong — that GoPHP5 did what it needed to do by hurrying PHP 5 adoption as fast as it could, and that WordPress slowed it down. It may be naive to think we didn’t have much to do with it, but if we did exactly what Drupal did, I’m guessing we’d be looking at the same numbers and timeline.
And unfortunately I’m going to be out of town for this week’s meetup! I’ll post the slides. It’s a good thing we’re on track to announce a bump in the minimum PHP 4 requirements well before then, otherwise I feel that’d have been quite the discussion. Yay, no need anymore to defend something that’s indefensible!
Agreed that they havenāt changed much from 4 to 5. The usage numbers weāre seeing with WordPress installs, though, show very little 5.3 in the wild. Thereās currently more WP installs running on 4.4 and 5.1 than 5.3.
I was talking about the PHP space in general, but I see how the WP space would be different. I may lurk in that dev discussion. I have a few times when Aaron tipped me off to them. š
On that note, since I’ve been jealous of how Drupal (and obviously WP) have *real* stats to support their specific communities, we implemented similar in web2project for our 2.0 release last month. It will take 6+ months until we have any real useful information, but we’re on the way.
Yeah, they’d definitely be different, but our PHP 5.2 numbers contrast so drastically with all the others that I’d think they are indicative of broader trends across the PHP space (though the trends we see in the WP space lag a bit behind the PHP space, for sure).
Awesome! Have you had the requisite mailing list riot yet?
“Thereās also exactly one installation reporting PHP 6.0. The more you know.”
Fascinating. Who is that? @tychay?
I knew you would take my comment down… you plonker š
Actually, your comment wasn’t made on this post, it was on a different one.
Finally got our host to upgrade us from php 4 this month – to 5.1.6
Changing hosting isn’t an option.
Unfortunately, you will have trouble using Drupal 7, Joomla 1.6, and WordPress 3.2 on PHP 5.1.6 — which was released more than four years ago, in August 2006.