Resizing and regenerating WordPress upload thumbnails

WordPressFor 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!

Site Redesign

Does this site look completely wonky to you? I’ve just implemented a new design! Most likely you’ve got some old files cached. Clear your cache and refresh (or, just refresh about 20 times and your browser will get the hint and clear the cache itself). Of course, you might also be using Internet Explorer 6, in which case my annoying alert dialog box should have already goaded you into upgrading. If that’s the case, enough said.

Does this site look a little wonky to you? In that case, then you are probably a better graphic designer than I and/or you’ve discovered that the new design isn’t 100% implemented yet. If I’m lucky, it’s the latter. At any rate, I’ve already spent far more time in the past 24 hours working on this than I’d have expected to, given the limited extent of the results, but I’m a little burned out, so I’ll be finishing a few things (like the background on the footer and a few other little graphical touches) over the next few days. Oh, and I’ve only done the bare minimum trying to update the “Offspring” pages to work with the new look. (It took me about an hour of hunting before I realized/remembered that some of the style settings for the gallery pages are actually in the plug-in settings in WordPress and not in the Gallery2 files at all.) But I am hoping to make the move from Gallery2 to the Dutch Monkey’s DM Albums plug-in soon anyway.

WordPress is great, but the documentation leaves a little to be desired…

Alas, the woes of using open source software rear their heads. WordPress abounds with undocumented, or at least very poorly documented, features.

My dilemma: the default function for displaying a list of page links (used on this site to populate the Points of Interest panel in the sidebar) sorts links alphabetically, and there isn’t any obvious way to make it sort by the database’s menu_order field, which logically, to me at least, should be the default especially given that this is how they’re sorted in the admin tool.

Finding little help in the documentation or by my usual means (Google), I decided it couldn’t be done without modification. In my previous installation of WordPress I actually modified the core code itself to change the sort order, but when I upgraded to version 2.1.1 today, it overwrote that change. This time I decided to try the plug-in approach, so my changes would actually stick through version changes, and so I could get familiar with the powerful but arcane plug-in system WordPress uses for extensibility.

After poking around futilely trying to get my plug-in to work (to the point where it was sorting all of my blog posts the way I wanted the pages to be, but not the page list), I stumbled upon a relevant post in the WordPress forums, where a snide jab at “theme designers” (which seemed to be such a broad swipe that it included me) happened to mention an input parameter in the function that calls the page list!

Silly me… the system has built right in a very simple way to sort the list by whatever field you want, and all you have to do is pass in the right parameters in your theme files. The change couldn’t have been simpler… but learning that it was possible certainly could have!

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 ]