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 — Continue reading

My DC PHP presentation

Via @DCPHP.

Last night I spoke at the DC PHP August meetup, hosted by Fathom Creative near Logan Circle.

The topic was WordPress 3.0, covering custom post types and taxonomies, multisite and the MU merge, and advancements in theme development. I also spilled the beans that we’re moving to PHP 5.2 with WordPress 3.2 (gasp!). I shared our development and release philosophies, and also had an engaging talk about security, BlindElephant, and shared hosting, which is always fun.

It was a great group (about 30 people) and a good warm-up for my WordCamp presentations this weekend at Savannah.

The presentation was 68 slides in all and lasted about 75 minutes. Without hearing the talk though, you wouldn’t know that the second slide was my first patch ever, but there you go. (I’ll be talking much more about that this weekend at Savannah.) You also wouldn’t know that I actually go into a spirited defense of shared hosts after boldly declaring they suck, so don’t read into the slides too much:

http://www.scribd.com/doc/36135238/WordPress-3-0-at-DC-PHP

On PHP

By lwr. CC BY-NC-SA 2.0

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. 1 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. 2

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. 3

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.

Continue reading

Notes:

  1. I look forward to discussing both when I speak at the DC PHP meetup in August.
  2. “Allowed return by reference from internal functions.”
  3. Version 3.0 was a very stable release, especially considering the massive amounts of refactoring that went into custom post types, the merge of WordPress MU, and improved custom taxonomy support. Plugins I have seen labeled as incompatible weren’t working right in earlier versions.