WordPress, I love you, but you drive me crazy

What’s even more extremely current than “bleeding edge”? Well, whatever it is, I’m not it. But I still try to keep my software as current as possible, and that includes updating WordPress whenever a new version is out. Most of the time, the difference is negligible, of course. Other than the major transformation of the admin interface with WordPress 2.5, very little actually changes as far as your site appears to the outside world. Which is good, for the most part, because you don’t really want unexpected changes on your site just because the underlying software is changed. It should all keep working just like it did before.

And there’s the problem: usually the only things I notice that are different when I run a WordPress update are things that are broken. That, and the fact that it’s a major pain to have to update the entire file set whenever a few changes are made. (It would be easy if I had terminal access to my server so I could upload the tarball, but no dice. I have to upload all n-thousand files individually.) So far I haven’t been able to find a reliable source listing exactly which files are modified from version to version.

That aside, what really frustrates me is when I do an update, like the 2.5.1 update that was released last week, and discover that none of my navigation works anymore. I still have no idea exactly what they did, but the old URL rewrites I was using — /%category%/%post_id% — crapped out. It seems like the %category% variable isn’t supported anymore, but I can’t find any documentation of that kind of change (nor can I comprehend the logic behind it, if it was in fact intentional).

Anyway, I discovered along the way that pretty much any of the rewrite schemes (at least, the 3 or 4 standard ones) seem to work, regardless of the one you’ve chosen as your “real” scheme. This makes sense because if you change the scheme, old links from other sites will still work. But my chosen custom scheme does not, anymore. So after some angry fiddling around, I settled on one of the standard schemes that’s almost like what I was using before, and everything seems copacetic, for now.

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.