A useful tip if you love both YouTube and markup validation

Not valid!YouTube is worlds apart from the likes of MySpace (*shudder*) when it comes to good code, but like most massively influential sites, they don’t really seem to care that much if their code validates, and even less if the code they provide webmasters for embedding content in their own sites does.

Frankly, I usually don’t care that much about validation either. I worked in this field for too many years when no validators even existed, and I’ve always taken the pragmatic approach: make it look and work the same, more or less, in all reasonably recent versions of Internet Explorer and Netscape (with Firefox and Safari having replaced Netscape over the past few years), and be done with it.

But I still have to admit that it’s a bit embarrassing that the “Valid XHTML” link (which appears in the Meta sidebar by default in WordPress) proves just how not valid my XHTML really is. I checked it today and was shocked to find 76 errors. I was relieved, however, when I dug in and discovered that only three of those errors had been my own. I had nested a <ul> inside a <span> (which I honestly didn’t even realize was a mistake, although I understand why it’s wrong, and it was easy enough to change from <span> to the valid <div> without any visible difference), and I had omitted alt attributes from a pair of images that don’t need to be identified by page readers anyway (and would probably be better off being worked into the CSS somehow).

These were pretty minor errors, if I do say so myself. 67 of the remaining 73 errors originated in cut-and-paste code blocks I got from PayPal and LinkShare (the latter of which I deal with only very reluctantly because they provide the mechanism for Apple’s iTunes affiliate program). What a surprise that the code from these sources looks like it was written by a tech support grunt in 1996 (in other words, by me in 1996)!

These were easy enough to fix, as well. I’ll just need to remember to fix them again if I ever change the code in those ad blocks, which I’m sure I will. The final 6 errors were the result of a YouTube video embedded in one of my blog posts. Ah yes, the age-old <object> vs. <embed> conundrum. I’ve always hated <object> because it seems unnecessarily complicated, with a slew of nested <param> tags that could just as easily have been attributes of the tag itself (although I suppose the point was to allow new parameters to be added without having to add support for new attributes in the DTD); plus it reeks of Microsoft’s platform-dependent ActiveX crapfest. I especially loathe the presence of, and need to hunt down, a ridiculously long, completely arbitrary clsid string representing the file format of the embedded file. (What’s wrong with a freakin’ MIME type?)

Unfortunately, the cleaner and more straightforward <embed> has never been part of any HTML specification, so it doesn’t validate.

Now it appears that there’s a solution to embedding YouTube videos in an XHTML-compliant way. Huzzah! But that means I’ll have to go back through all of my posts that have YouTube videos in them (which is a surprisingly large number) and fix them. It should be easy enough to hit them all at once with a well-constructed SQL query; I just need to study the pattern and do it. In fact, if I’d spent the last 15 minutes studying the problem instead of just complaining about it, I’d probably be done already.

But sometimes, complaining’s just more fun.

A fix for a fix in WordPress 2.1

One thing that surprised me when I started using WordPress again is that its search function only searches on blog posts, not on static pages. I suppose if most WordPress sites are 99.9% blog posts, then it probably makes sense, but I have enough static pages on my site that I’d like to make searchable to warrant changing this.

Fortunately, someone has. Unfortunately this “Search Pages” plug-in is out of date and no longer works with current versions of WordPress. I dug in a bit and figured out why: the plug-in alters the SQL query that performs the search, but the substring it replaces in the query no longer exists! So I hunted down the place where the query occurs in the WordPress core, adjusted the plug-in as needed, and it works!

Here, then, is my hack of the Search Pages plug-in, modified to work with WordPress 2.1. (I’m not sure which other versions of WordPress it will or will not work with.)

[ search_pages.php.tar.gz ] [ search_pages.php.zip ]