At the risk of this getting drowned out with everything else abuzz in the WordPress community:
On Thursday, I am visiting GoDaddy headquarters. Please post any questions you may have for them and I will see to it that I can get them answered.
Some background: GoDaddy hosts a few hundred thousand WordPress sites, many through a special package. They have been bitten by the same attacks affecting other hosting companies. I previously mentioned GoDaddy when compiling my thoughts on WordPress security and the shared hosting attacks, and I didn’t mince words then.
A few weeks ago I was testing some plugins and realized it was about time I write an update to Stephen Rider’s Log Deprecated Calls plugin. I don’t like reinventing the wheel, but there were a few reasons I wanted to start anew.
I spent quite a bit of time early in the WordPress 3.0 development cycle improving our deprecated notices. We added reporting of deprecated arguments and I tediously went back through the SVN history to find the version numbers for every deprecated function, both when the function was introduced and when it was deprecated. We also formally deprecated a number of functions, such as the really old widget API — e.g. use wp_register_sidebar_widget(), not register_sidebar_widget() — and the old escaping aliases — e.g. use esc_attr() instead of attribute_escape().
So, I wanted to make sure there was a plugin to fully leverage all of this. Stephen indicated he wanted to update his plugin to handle arguments (originally released for WordPress 2.6), but that he was also working on integrating it into his own plugin framework. I wanted to scrap the extra table and leverage a custom post type for both the storage and the UI, and see how far that would get me.
The results were interesting. I’ve made some pretty interesting customizations to allow me to leverage the custom post type UI, and the plugin is scattered with notes on possible enhancements for WordPress 3.1 that can help a lot of plugin developers, which I’ll revisit when we start development in September. In hindsight I think leveraging the UI was a wildly successful experiment, even with the hacks I employed to make it work to my liking, because I didn’t have to worry about any overhead.
Feedback and bug reports are encouraged. The plugin is available in the WordPress Plugin Directory. Here’s the source. The current version is 0.1-RC1.
Update: I have since updated this plugin. Want to learn more? Check out more recent posts.
When writing “On PHP”, I realized I needed footnotes. A search of the plugins directory revealed a number of plugins, but most were either old, overly complicated, or needed some work. I needed something dead simple.
Twenty minutes later, I had a quick plugin serving my need. Jeff Waugh asked me about it, and so here it is.
A whopping forty lines of code, it leverages the ref shortcode and ↩ as the return arrow. Style it yourself — I have some code in my child theme of Twenty Ten. 1 I can think of a few things I could add to it, like being able to optionally number footnotes yourself (would be helpful if you added one later) or customizing little things like display options. But for now, it’s simple, and it works.
Feedback encouraged of course. The plugin is available in the WordPress Plugin Directory. Here’s the source. The current version is 0.2.
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.
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.
“Allowed return by reference from internal functions.” ↩
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. ↩
We slated menus for WordPress 3.0 during our developer’s meeting on January 7. After not getting very far over the next month — a lot of that due to our focus on custom post types and the MU merge — we noticed that Woothemes released their system (they did so on January 27). We had been struggling with the concept (early patches used the widgets code as a base) and their take seemed like an interesting angle.
After they contributed a giant patch, we switched the schema over to a custom post type and taxonomy, rewrote a lot of the code to conform to our coding standards, and started to build out an API. After a round of usability testing, we made some numerous design and UI changes. We also needed no-JavaScript support and RTL support, and our new UI called for new JavaScript, so most of everything ended up being rewritten.
Point is, that’s how it works. It’s called iteration. In an open source project, iteration happens very publicly. I can think of a handful of patches I have personally written or committed that ended up getting modified extensively later in the same development cycle, or in some cases outright refactored or removed. This doesn’t make the contributions less valuable. Of the hundreds of patches I have written, many iterated existing code written by others. It’s called a patch for a reason. As we evolved the custom post type system, tons of code got rewritten, some of it dating three years and some of it three days. As we merged in WordPress MU, thousands of lines of code written by Donncha and contributors to MU were in some cases entirely rewritten or simply deprecated and removed. This is how a project evolves, grows, and strengthens.
Menus were a collaborative effort among dozens of developers. The first contribution to the effort, by Jeffikus of Woothemes, was very important. It was a very sizable contribution that then drove our stalled development in the direction we were grasping at for some time. But it was also just the first of hundreds of iterations (like any other major feature) — the patch was an early prototype of a feature we wanted to scale to millions. Like every other individual pouring mind and soul into the WordPress project (more than 200 contributed to WordPress 3.0, dozens on menus), they absolutely deserve credit for their efforts, on top of the respect they have earned for contributing commercial code to the project.
