So, if you’re curious, read on to find out how I set it up. It really was quite simple. I first downloaded and installed WordPress using their 5 minute install guide. After that, I followed the instructions for importing from MoveableType. The most difficult part was making sure my permalinks from MovableType (like the archives) still worked. To do that, I created an .htaccess file to leaverage mod_rewrite. It looks like this:

RewriteEngine on
RewriteRule ^archives/0*(\d+).html /~jake/blog/index.php?p=$1
RewriteRule index.rdf /~jake/blog/index.php?feed=rdf
RewriteRule index.xml /~jake/blog/index.php?feed=rss2

So, we’ll have to see how well this really works for me, but at this point I’d have to say that I’ve already committed to it.

I did run into a couple of problems when trying to install it. After following the instructions in the README file, it still wasn’t working. So, I ran the scodetest.cgi script. It kept telling me that my temporary directory wasn’t writable by the webserver, which I knew to be an incorrect statement. So I did what any reasonable person trying to install a plugin would do: I started looking at the code. It really is a simple module, so it didn’t take long to figure out what was going on. The scodetest.cgi script as well as the mt-scode.cgi image generation script were calling MT::SCode::scode_get($code) to retrieve a security code. There was an if block in that subroutine that would call scode_generate() and return that subroutine’s return value as the return value for scode_get. That seemed like the right thing to do, but it wasn’t. The problem is that scode_generate() doesn’t make any effort whatsoever to save the value that it generated so that it will be associated with the $code originally passed to scode_get(). This is what was causing the scodetest.cgi script to always say that my tmp directory wasn’t writable (that script simply calls the scode_get() routine twice and checks to see if it got the same result both times). So, I modified my scode_get() routine to call scode_create() (which calls scode_generate() and saves the value) instead of scode_generate(). The relavent portion of that subroutine now looks like this:

# Random number back...if have not initialized
if ($code< =0 || $code>$scode_maxtmp || !-e $tmpdir.$code ) {
return scode_create($code);
}

Because I’m still trying to return this random value to whatever called scode_get(), I needed to modify the scode_create() subroutine to return the generated code. My new scode_create() routine looks like:

sub scode_create {
my $code = shift;

return if (-e $tmpdir.$code);

my $scode = scode_generate();
if ($code>0 && $code<=$scode_maxtmp) {
open(OUTFILE,">${tmpdir}${code}");
print OUTFILE $scode;
close(OUTFILE);
}
return $scode
}

And now everything works. The only other issue I noticed was an incorrect usage of the alt tag for an image in the installation instructions. The alt tag is not supposed to be used as a tooltip, but as alternate text to display when the image is unable to be displayed. As such, it should say something like: “Image required in order to post.” The tag that should be used for the text “Please enter the security code you see here” (what the plugin author put in the alt tag) is the title tag.

<!-- JANUARY_2003 -->
<table border="0" cellspacing="4" cellpadding="0">
<caption class="calendarhead">January 2003</caption>
<$MTInclude module="CalendarDOW"$>
<MTCalendar month="200301">
<$MTInclude module="CalendarDays"$>
</MTCalendar>
</table>
<!-- /JANUARY_2003 -->

That’s still a lot more than should be required had a better templating system been used. It would be nice to have all that layout type stuff in one template module so I could just say something like <MTInclude module="Calendar" month="200301"> and still be able to get my own layout, but I this is still better than what MoveableType uses by default.

UPDATE: I was just looking at the 2004 Archive page. With this entry, I’ve now posted more in the month of December than I have for the entire other 11 months of 2004. Kinda sad, isn’t it?