Recently in Movable Type Category

Plugins that I installed specifically for Movable Type 6, and plugins provided with Movable Type 6 that I disabled by removing them from the /plugins directory.

This post describes the list of plugins I had in my Movable Type 3 installation, and why I chose to include them in the Movable Type 6 installation by copying them to the /plugins subdirectory of my Movable Type 6 installation, or not include them, before I performed the actual upgrade to Movable Type 6.

Upgrade Type

  • Parallel installation of MT6 to new subdomain
  • Upgrade on copy of MT3 MySQL database

If something went wrong during the upgrade, I could revert back to the original version, or recopy the database and try again. Plus, I will have the original installation as a reference point if I wanted to see how something was in the old installation, which I had not looked at in the past 10 years.

  • Install MT files to single directory

My web host allows execution of .cgi scripts from any directory, so I did not need to install the MT files to a cgi-bin directory, nor did I need to install the mt-static files separate from the main MT files.

  • Copy MySQL database

To copy the original database, I used phpMyAdmin in cPanel to create a new database, then exported and downloaded the MT 3.33 database to a file, then used phpMyAdmin again to upload the export file and import it into a new database.

To make things easier for me, I granted the MT 3.33 database user permissions on the MT 6 database (again, using phpMyAdmin), so the database user and password would be the same between the databases.

  • Set the permissions on all .cgi scripts to 0755.

The return of


After almost a decade on hiatus, is back with new Movable Type software and a new look.

For the last 10 years, the blog was stuck on MT version 3.33. Movable Type has been upgraded to MT 6.1.2 - the most current release as of this date.

In future posts, I will describe my experience upgrading from MT 3.33.

R.I.P. MT-Blacklist


Due to the increasing abuse of the master blacklist file on Jay Allen's server, culminating in its being hit 2.4 million times over a 4 day period, MT-Blacklist and the master blacklist are now dead and won't be coming back.

Thank you, Jay, for providing MT-Blacklist when it was needed most and putting everything you did into it to keep it working for as long as you did.

P.S. 2.4 million hits isn't a quarter of a billion, but it's still a helluva lot. ;)

The SpamLookup 'Keyword Filter' plugin provided with MT 3.2 works in a similar manner to MT-Blacklist (which SpamLookup hopes to make obsolete), but there are some differences in the way it works with keywords and regexes compared to MT-Blacklist. This post will explain some of those differences so you can understand how SpamLookup's 'Keyword Filter' uses the keywords and regexes when it is filtering spam, and perhaps experience a smoother transition when migrating from MT-Blacklist.

Movable Type 3.2 introduced a new status for comments and trackbacks - 'junk'. Rather than blocking comments and trackbacks that are deemed to be spam, such comments and trackbacks are kept in the system. How long these 'junk' comments and trackbacks are kept in the MT database is controlled by following settings, found on the "Feedback" tab of the weblog's "Settings" page:

Auto-Delete Junk:

  • If enabled, junk feedback will be automatically erased after a number of days.

  • This setting controls whether you want to have junk comments and TrackBacks automatically deleted after a certain period of time specified in the next option.

Delete Junk After X days:

  • When an item has been marked as junk for this many days, it is automatically deleted.

  • This setting defines the number of days since a junk comment or TrackBack was received or marked as Junk until the item is deleted.

    The value of this setting depends completely on how often you look in your Junk folder for false positives. The default is 60 days, but most people will be satisfied with 7 days.

When "Auto Delete Junk" is enabled, the deletion of junk comments and trackbacks is not truly automatic (despite what the MT documentation says). MT will only "auto-delete" junk comments and trackbacks when you browse to a weblog's main admin page in MT (the page displayed when click on a weblog's title on the main mt.cgi page). If you never browse to this page, which is surprisingly easy to do with all of the new weblog shortcut links present in MT 3.2, MT will not delete old junk comments and trackbacks.

One of the latest tools for fighting MT comment and trackback spam is Brad Choate's SpamLookup plugin. I have it installed here along with MT-Blacklist, and between the two of them, well over 99% of comment and trackback spams are blocked automatically.

Joe Katzman at Winds of Change submitted a SpamLookup ticket, asking for the ability to approve trackbacks blocked by SpamLookup. I e-mailed this reply to Joe's ticket:

Blocked trackbacks are literally blocked. They are not saved into the MT database at all, so there would be no way to later approve them.

In order to approve trackbacks, MT must have the ability to moderate them. MT currently does not provide the ability to moderate trackbacks, nor does SpamLookup. If you want to be able to moderate and approve trackbacks, you would need to install Chad Everett's MT-Moderate plugin, which can be downloaded from his web site.

SpamLookup is aware of MT-Moderate, so once you have MT-Moderate installed, it should properly moderate trackbacks if you configure SpamLookup to do so, and give you the ability to later approve moderated trackbacks (on the Trackbacks page in both SpamLookup and MT).

If you already have MT-Moderate installed, but still cannot moderate or approve trackbacks, that would most likely be an installation or configuration issue.

Moderation of trackbacks is a feature that has been long missed in MT3. MT-Moderate fills that hole nicely, and it's even better when paired with SpamLookup.

While reviewing my referers, I ran across an entry on Tiny Pineapple that discussed how my Replacement for MTCommentFields no longer worked in MT 3.16:

But after a recent upgrade to Movable Type 3.16, it stopped working. And after poking around a bit, I figured out why.

In addition to <MTCommentFields>, Movable Type 3 also introduced a new, but undocumented, template tag called <MTIfNonZero>. The only reference to it you'll find in the Movable Type documentation is in one of the Category Template Tag examples:

<MTIfNonZero tag="MTCategoryCount">
<li><a href="<$MTCategoryArchiveLink$>" title="<$MTCategoryDescription$>">

From the example we can deduce that you can use <MTIfNonZero> to determine whether or not the value of a certain template tag is zero. But TweezerMan went one step further and used it to determine whether or not the value of a variable was equal to zero. And to do so, he used two different syntaxes:

<MTIfNonZero tag="GetVar" name="preview"><$MTCommentPreviewAuthor$>


<MTIfNonZero tag="MTGetVar" name="preview"><$MTCommentPreviewAuthor$>

But while those may have worked in Movable Type 3.15, neither seems to work in Movable Type 3.16.

This got me to wondering: Did Six Apart really change the behavior of MTIfNonZero tags in MT 3.16?

From the Movable Type web site:

Version 3.15 fixes a vulnerability in the mail sending packages for all Movable Type versions which allows malicious users to send email through the application to any number of arbitrary users.

All users should install this update.

This release fixes a nasty bug where a malicious user can (among other things) post a comment to an MT weblog and cause comment notification e-mails to be sent to any number of recipients they choose.

As noted above, the bug is present in all versions of MT - all 3.x as well as 2.x versions. To secure your MT installation, you can either 1) upgrade to MT v3.15, or 2) install the newly-released plugin ( The plugin will correct the vulnerability in MT 3.x installations prior to MT v3.15 as well as MT 2.661 (the plugin has not been tested on MT 2.x versions other than MT 2.661).

Spammers are already exploiting this flaw on MT weblogs, so it is very important to upgrade to MT v3.15 or install the new plugin as soon as possible.

Special thanks to Six Apart for their quick action on this issue. Total time from reporting of flaw to release of fix: 48 hours. (I know this because I reported the flaw.) Considering the flaw was reported on a Saturday night, this was an excellent response by the Six Apart team!

Update 26 Jan 2005: Total Choice Hosting (TCH) installed the plugin yesterday on all MT installations across all TCH servers to proactively protect their customers.