The other day, I wrote the popular 10 Things You Need to Know About WordPress 2.9. As usual, most people are very excited about the new release which is now in beta and available for testing. In the article, I made a few fundamental errors which I have since corrected.
Notably, I mentioned that WordPress 3.0 would be going to PHP 5. This was based on conversations I had with a core developer which I now realized I misunderstood. Kinda. WordPress will probably not be dropping PHP 4 support in WordPress 3.0 but as core developer Mark Jaquith suggests:
Some things already require PHP 5, like time zone support or oEmbed. There are no plans that I know of to remove PHP 4 support in 3.0 “” last I checked we still had 12% of WP installs using PHP 4.
I see more of a natural and gradual deprecation of PHP 4. We’re very much open to making new features require PHP 5 if it would be a pain to make them PHP 4 compatible.
As a PHP developer, I am on board with calls for PHP 5 support. PHP 4 has been end of life (EOL) since August 8, 2008. That basically means that there will be no more releases, no more security patches, no more nothing. It’s done. Stick a fork in it. However, as Matt mentioned on stage at WordCamp NYC this weekend, there are still 12% of WordPress installations using PHP 4 hosting. He breaks that down as approximately 2M installs, the size of a major American city. More precisely, that’s approximately the size of Philadelphia.
This is not to defend WordPress development. I’d leave Philadelphia behind in a minute if I could get access to real object oriented PHP, reliable XML parsing, better HTTP transports and so much more. Yes, Philadelphia… I just threw you under the bus. That’s for signing Mike Vick. However, as Mark suggests, increasingly more features are being added to the core that require PHP 5.
oEmbed, which will ship in WordPress 2.9, requires XML or JSON parsing. XML parsing sucks in PHP 4. JSON ships by default in PHP 5.2. It is easier to backport JSON support to PHP 4 than try to engineer XML parsing for PHP 4. Some in the PHP community feel like backporting a PHP 5 feature to PHP 4 disincentivizes PHP 5 movement. It may, I’m not here to argue that.
Time Zone support is handled via the PHP class DateTimeZone, a PHP 5 class. Of course, on PHP 4 hosts, the user simply has to set the UTC offset (say, UTC-5 for Eastern Standard Time) manually. Graceful degradation.
I personally was one of the first people to write code for the SSH2 portion of the one click automatic upgrade feature. I, of course, did not go very far with it, but I was the one who first took a stab at creating that.
It is not worth it for PHP developers to throw mud at WordPress developers and the PHP 4 requirement if they are not willing to write code to make it better. Writing code does not, of course, mean that your feature will be incorporated. But this is an open source project. If you want to see new features, and the developers have indicated willingness through not only words, but also action, to include PHP 5 features, then you need to be the champion of those changes. In other words, you need to write the code, submit the ticket and state your case. Even if you can’t write the code, open a ticket and be a champion for the case.
Effective arguments, however, do not include holy wars over PHP 4 or PHP 5. Effective arguments do include security, usability, and feature requests that reflect “must have” features. Is it plugin territory or should it be a core feature? Why? State your case.
I will admit not being overly active in the ongoing development of WordPress. I have client work built around WordPress, so that takes up most of my time. Understanding that, I also have no room to throw mud unless I’m willing to step up and write code too. It’s sort of like voting. If I don’t bother to go vote, then I can’t complain about my elected officials.
If you want to see change in WordPress, be that change and put your words into action.