Tag: PHP

Keynoting php[tek] in Chicago, May 14-17

I’m excited to announce I’m giving a keynote address at php[tek] 2013. It’s a fantastic PHP conference put on by the folks behind php|architect. “The premier professional PHP conference with a community flair,” #tek13 has a rockstar speaker line-up, four tracks of content, and a day of training. I’m thrilled to be attending the conference — I also attended #tek11 — let alone speaking.

Last night I tested a few ideas at the DC PHP meetup and got some great feedback from the attendees. Some early reviews:

https://twitter.com/wardnetinc/status/322140560523673601

https://twitter.com/kingkool68/status/322151835756544000

https://twitter.com/openwestconf/status/322393612249886720

I’m continuing to conduct a lot of research for this talk. There’s a lot WordPress has learned over the years, so I’ve been searching through the codebase and old commit messages, as well as compiling a ton of data and statistics. If you have anything you think might help, please contact me. Here’s the full talk description:

WordPress is Everywhere: Extreme Portability as a Double-Edged Sword

WordPress has tens of millions of users worldwide and powers over a fifth of new sites. But such a large and diverse user base presents unique challenges, and as it approaches its tenth birthday, the WordPress codebase is showing its age. So why is it so ubiquitous?

The answer lies not in its UI, UX, ecosystem, or community, though those are certainly among its strengths. The answer lies instead in a core philosophy that holds the user above all else.

This user-centric design starts not with the interface, but rather with the code itself. Developers should approach software development with an unwavering promise they will deal with the nonsense instead of passing it off to the user.

Some WordPress positions might seem draconian and inflexible. Backwards compatibility is almost never broken. The technical requirements appeal to lowest common denominators. But because the project maintainers deal with all the pain — technical debt, difficulties with PHP, working on as many server configurations (and misconfigurations) as possible — its users don’t have to. Thanks to the WordPress project’s portability efforts, you can pick a web host or a PHP configuration at random and WordPress will run on it. Because of this, adoption has soared.

The way WordPress operates is not for everyone. But whether your projects are used by 10 users, or 10 million, it may help you to see your code in an entirely new light.

Tickets are still available. Hope to see you there!

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 On PHP, Redux

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 On PHP

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