One of the Big New Features in WordPress 2.2 was a dynamic sidebar. The idea was that developers would write reusable Widgets that users could add to their sidebar through drag-and-drop—a huge improvement over the old method of modifying a bunch of PHP by hand. The good news is that building a sidebar from widgets works great. Unfortunately, the bundled widgets don’t. The archive widget has an invalid capitalization of its onchange event that keeps this site from validating, while the links widget serves up duplicate IDs if you have links in multiple categories. No software is perfect (sadly including my own), but there’s a difference between having a few random bugs, and failing profoundly at something integral to your product—in this case, generating valid XHTML. The second bug in particular is surprisingly severe, since having duplicate IDs breaks the DOM and violates not just XHTML, but also the generally more bug-tolerant HTML 4.

What I don’t understand in looking at these bugs is why they happened in the first place. HTML validation can be trivially automated on a build server; it’s equivalent to verifying that the code you check in compiles (something which indeed frequently is automated on build servers). Shipping validating XHTML is something that the developers should be able to get “for free.” Yet it’s apparently not part of their process. The bug for the onchange mistake, for example, didn’t get filed until July—several months after WordPress 2.2 shipped.

Even if HTML validation were part of their build process, I’m not sure it would have helped much: the duplicate ID bug was filed the instant WordPress 2.2 came out, but making a fix has been pushed to WordPress 2.4, due sometime in 2008. They had to do this because the underlying bug is actually in the core of WordPress, which means fixing it would be hard.

What good is knowing about bugs when you’re not willing to fix them?