Oddball Update

I love it when a plan comes together! Or more accurately, when you find a solution to a computer problem—in my case, two. For the last few days I’ve been upgrading the “Classic Oddball” archive on my local machine, and gifting it with the backbone of a new weblog system. Since the first weblog tool I ever used was Movable Type, I’d been using it as the underpinnings of Classic Oddball since the beginning. Movable Type is CGI-based and must rebuild a series of static pages each time you make any changes to its database. For some reason, lately, that rebuilding process had been failing, such that half of my entries were getting truncated right out of the database. This was unacceptable.

I decided to ditch the lousy CGI crap and upgrade to Wordpress. I had once auditioned Wordpress on this here site, but back then it didn’t have the features I needed. The latest release, v1.5 “Strayhorn,” has all of those features—actually, to the point where I’m leaving it open for consideration in case I ever want to revamp this site. But, it seemed perfect for Classic Oddball, especially since it used dynamic PHP pages instead of CGI. So I downloaded it, set it up, and imported all of my old entries, all the way back to 1994.

Everything went pretty smoothly, but I was instantly reminded of something about Wordpress. While it’s much more easily customized than the system I use here on the live Oddball, it also requires much more hands-on coding and customization to get it where I wanted it. Had the same issue with it when I briefly used it on this server, and ultimately abandoned it because it just couldn’t do certain things consistently. They’ve solved a lot of those problems, though, and I’d wager that version 1.5 is the best version of Wordpress ever. While it took some work, and some studying of the PHP online manual, I got everything working exactly as I wanted it. Except one thing.

On the old Movable Type-based Classic Oddball, I had a little panel on the sidebar that would list other posts written on the same day as the one you were currently reading. You know, so if you were reading an entry made on April 4th, 2005, and there were other posts in the database on April 4th but from other years, a short blurb from each of those posts would show up in the sidebar, as well as a permalink to click on. That functionality was a plugin for Movable Type, not a built-in feature. Wordpress didn’t have it built-in either, so I hunted down a plugin. In the end, I found three that came close to doing the job…and one that came very close…but there was something not right about all of them.

Two of the plugins were written in such a way that the current date was always used as the reference. So, you might be reading an entry from February 12th, but if the current day was July 27th, the plugin would look for all posts made on July 27th. That’s not what I wanted. I liked to use the feature as a way to see a snapshot of what I was thinking about on the same particular day over a range of years. So that on the same day last year that I wrote something about my job or what-have-you, I could see that in 1995 I was thinking about Doom or going to school the next day. Kind of an interesting way to muse on anachronistic references.

The third plugin I found worked the way I wanted it. It used the entry post date as its reference point. But you could only use it within the PHP routine that culled the posts from your database for display—meaning, essentially, that the output would have to go somewhere in the main portion of my screen. I wanted the output on the sidebar, not all the way at the bottom of the page under the post, or floated to the left, or anything like that. I tried sticking the code out in the sidebar, but couldn’t make it work.

In the end I finally found a solution. I came up with a rather quick-and-dirty, but ultimately effective, way to call the “On This Day” plugin from within the post loop, but display its output on the sidebar. Since the code for the sidebar and the main window were in two different files, I couldn’t carry over PHP variables from one to the other. So I drew a hidden DIV tag (display: none), put a form in it with a hidden input, and wrote the plugin output into the form using the PHP htmlentities string processor. This processor converts all non-alphanumeric characters (quote marks, apostrophes, etc.) into HTML entities, so that you can put ‘em in a form field and not break the coding on the page.

Then, on the sidebar, I use the tired old document.write Javascript function to grab the contents of that field (if it exists, and if it is not empty) and place it in the sidebar. The actual content pane that holds the post excerpts isn’t even drawn if there isn’t any data in that field, so you never see an empty box floating over there (as I did on the old Movable Type system, which was annoying). At long last, the “On This Day” sidebar was working again—and it was all dynamically driven from the database with PHP.

Now, for my second problem. There was something screwy with the code for the “On This Day” function. At least, that’s the only way I could explain the fact that there was one post in the history of Classic Oddball which would fail to display properly as long as that plugin was active. It would fail in a strange way, too—it looked like Apache would just stop serving the content, so abruptly the HTML would be truncated at a certain point. At first, since it was happening only to this one post, I thought it was something in the post content itself. But even if I completely cleared out the entry body field, the page still got truncated before it could even draw the empty box. And as I changed the amount of content in the entry box, the page got cut off at a different and random point each time. It was the wackiest shizz I’ve ever seen.

The Apache logs weren’t revealing anything, so I figured the error had to be with the PHP preprocessor instead. But no PHP errors were being generated. It was just flat-out strange. On a whim, I decided to bring my version of PHP up-to-date. Checking phpinfo() I saw I was still running version 4.3.1, which was released two flippin’ years ago. Yeah, updating might be good. I also noticed that I had configured it to run as CGI instead of as an Apache module, probably because I was a lazy n00b and used the PHP Windows auto-installer last time, which sets it up that way and doesn’t give you the option to run as an Apache module. Ugly, ugly, ugly. So I removed PHP altogether and downloaded the manual-install 4.3.11 package.

A few minutes later, I had PHP up and running as an Apache module, and my mysterious “post truncating” problem was utterly solved. Ha! An outdated build of PHP was the answer. I also noticed an incredible increase in page loading speeds, even on my local server. This is why running PHP as a CGI sucks so frickin’ much, and why I left the new web host I tried for a month in March. Anyone who runs PHP as CGI should be schooled hardcore.

Indeed, it’s occured to me that the old PHP version was why even my Movable Type system had been hacking up my entries, too. In fact, it most likely was. But I’m still not going back to Movable Type. The old, kloogy CGI and static page rebuilding days are over for Classic Oddball.

So, now I’m wanting to get out of the office so I can head home and mess around with the old Oddball archives some more. Back in the day I would assign a numerical rating between 0 and 10 to all of my entires, which was sort of like an indicator for how bad of a mood I was in. While those have always just been bits of text written into each entry, I’ve decided to go back and actually set that value up in a custom field. I haven’t figured out how to do any operations on that field yet, since I haven’t investigated how it gets stored, but ideally I’d like to be able to sort entries by “crappiest mood” for some additional, yet still utterly pointless, fun. Heh heh. The only problem is that Wordpress stores all of its custom fields as a key:value pair of strings, so I can’t do numerical operations on the value unless I convert it to an integer first. (Hmm…PHP manual time!)

And this is really minor and unrelated to weblogs, but it is a technological problem that I’ve solved, so I thought I would mention that I have completely and utterly removed an email alias I’ve been using on my other domain because I was getting flooded with spam there, and the spam rate was only increasing. Fortunately, this is a throwaway alias I created for that exact purpose—in case it found its way onto a spam list—and used only for online service usernames and other shizz, so it’s no problem to change it. Except…I have to go to every account I have on pretty much every website and change my email address, which sucks. But it’s so incredibly nice not having to wake up and immediately delete 10 spams every morning. And that’s just what got through the SpamAssassin filter—I was getting like 70 or 80 spams a day in total, including what was filted out. Stupid crap. Now they’re all going to /dev/null, so enjoy your meal, spammers.

Edit @ 2:30 PM: Sweetness…regarding operations on that custom field I was talking about one paragraph up, I just coded up a page that will pull the ten entries with the highest scores on that custom field, display their titles, post dates and excerpts and link to the entries themselves. And in the process I learned how to do INNER JOINs in MySQL. Loving it.

Categorized as Computers