Tag: Wrong

Resizing and regenerating WordPress upload thumbnails

For quite some time, I’ve been wishing the thumbnail images WordPress creates when you upload an image were slightly bigger. The function that generates the thumbnails accepts a maximum dimension as an input parameter, but then the value (a paltry 128 pixels) is hardcoded in the script that calls the function, and there’s no way in the standard WordPress configuration to change the value, other than manually editing the admin script where the call is made.

This is easy enough to do, if you know how to find the block of code in question, but it’s wrong wrong wrong in terms of ongoing WordPress updates: when a new version is released and you update your files, the changes you made will be lost.

So the right way to go about this is with a plug-in, and fortunately there is one. It’s simple and it works. Except for the fact that it doesn’t regenerate any of your existing thumbnails.

Maybe there’s something else out there, but I wasn’t able to find one, so I had to resort to rolling my own.

The script is incredibly rudimentary right now. It’s not a plug-in, it doesn’t interface with WordPress admin at all, setting the file path and dimensions require manually editing variable values in the script, there’s no security, etc. It does seem to work though, which is the most important thing. There were a few bugs earlier on that I believe I’ve squashed, but I can’t guarantee there aren’t others, and given how quickly I put it together this afternoon, with kids screaming and car dealerships calling me every 3 minutes (yeah, that’s another blog post), it’s probably not quite as efficient as it could be. (That’s why I cranked up the max_execution_time and memory_limit values. YMMV depending on how many files you have to process.)

As long as you understand that you’re using it at your own risk, feel free to download the script. In order for it to work it should be placed in your wp-admin directory. And remember, it’s not secured at all, so I recommend uploading it, running it, and then deleting it. (Well, now that I think about it, I’m pretty sure including admin.php does automatically provide standard admin security, but don’t quote me on that.)

If I have the time and if anyone actually cares, I’ll update this and turn it into a proper plug-in with all of the attendant niceties. Otherwise… well… never mind!

A useful tip if you love both YouTube and markup validation

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.

‐.‐‐‐.‐‐‐‐..

Wow. For all my many years of waxing and waning Rush fandom, including having played several of their songs on the bass myself in a band a few years back, I never knew this about one of their oddest songs, the instrumental track “YYZ.”

Yes, of course I know YYZ is the code for the Toronto airport. But what I never realized, even as I was playing that rhythm, is that the opening of the song spells “YYZ” in Morse Code!

(I must admit I have some misgivings about saying I never realized it. I vaguely recall that as my bandmates and I were working the song out — from memory, not a recording — I was convinced that the last part of long beats was 5 and not 4, but the other guys might have used the Morse Code argument to prove me wrong. In fact, even tonight as I read about this and played the song in my head, I was still thinking it was 5, and, in my usual cocksure way, thinking “these websites have it wrong!” or “the band messed up the ‘Z’!” But then I actually listened to the song and realized it’s 4. Then I assumed the band I was in must have played it wrong, since I was so sure it was 5. So I listened to our recording of it and sure enough it was 4 there too! I guess the only thing that proves is that once again, it’s a bad idea for me to stay up too late on a Saturday night surfing the web.)

Here’s some more on the matter…

While I’m on the subject of Rush, I quickly googled (yes, it’s officially lowercase now, much to Google‘s chagrin) and was surprised to discover that, apparently, my high school friends and I are the only ones in the entire wired world who ever thought the band’s self-titled debut album cover looks more like it says RLISH than RUSH.