While the dynamic publishing model of Movable Type is not heavily used, it is actually a very useful feature. Probably not as a complete CMS - mostly because it is not full-featured - but certainly to provide some nice functionality on the side as it were.

Unfortunately the dynamic publishing functions are not documented much, if at all, so when you run into some issues, it can be difficult to troubleshoot. One of the more common problems you may find is an error message such as this one - when you cannot redeclare the 'MT' class, it will prevent the entire dynamic publishing subsystem from starting up, and you will be dead in the water!

Have you run into this error while trying to update your plugins from the legacy-style Perl format to a brand-spanking-new YAML layout, only to find that you can't seem to figure out just what the problem is? Spending hour after hour troubleshooting and still getting that annoying message and it just won't go away?

Look no further, because this one is easy. Well, sort of. You do have to look a little bit, but you actually are not missing a semicolon or a brace or anything along those lines. In fact, it might be a little hard for you to find, you just have to know where to look.

Generally you will see this as a longer error message, typically coming from the ContextHandlers.pm module, with a particular line number, something like this:

Can't call method "entry_based" on an undefined value at lib/MT/Template/ContextHandlers.pm line...

The message may seem obscure when you receive the message, but in actuality, it just means that you are using a template tag that the publishing process cannot handle. You just need to remove it (or replace it with a tag that will function properly).

Now that you have Slimbox up and running, you don't really want to manually create a bunch of links to it, do you? I mean you can, simply by adding the standard rel="lightbox" tag to your photos. But what if you have a bunch of photos? Or more specifically, what if you have a bunch of photos?

At that point, you have a couple of options. You can list them individually, which is certainly an option, but it gets messy very quickly, or you can use MT-SmugMug to fill in the blanks for you. That makes it a whole lot nicer.

The debate between dynamic and static pages is probably one that will go on for all time. If you are a fan of Douglas Adams, and believe that his work represents a possible outcome to the universe, perhaps it will even go on beyond time. If so, order me something if you happen to be dining at the end of the universe.

Nonetheless, it is quite possible that the best possible performance for Movable Type users is actually not dynamic or static, but a combination of the two. The reason being is, quite simply, because there are places that you can make use of both to maximize the benefits that both technologies offer.

Have you been publishing something in Movable Type and received an error that included this message or one like it? Maybe instead of "styles", your message was "feed_recent" or "javascript". What in the world does it mean? Luckily, the answer is really simple, it's just a matter of figuring out where to find the answer.

The details are all in your error message. It will tell you what was being published: Usually a particular tag within a specific template. That's the template you need to go to, and in that template, you need to check for the missing value, to determine what you need to do next.

Movable Type version 3.2, released in April of 2007, included a plugin known as SpamLookup. This plugin was able to submit comments to a lookup service (hence the name of the plugin) to one of a number of blacklist services, which in turn would determine if the IP address used for the comment submission is suspicious, allowing you to better judge if you had encountered a spam comment.

However, way back in May of 2007, Six Apart released a guide on updating your spam filters for the plugin. Without the change, your comment-posting process will be horribly slow, because the process has to timeout before it will continue. Also, the default for the other service probably isn't the best (though that isn't mentioned). Want to know more? Read on!

From time to time, I am asked how to display related entries on a Movable Type-powered site (and I frequently have to look it up myself), so I figured that I'd document it here.

While there are plugins that do the work, they typically depend on another value (usually categories, keywords or tags - sometimes a combination of those), and the problem with those is that they depend on humans to first enter that value. If you forget to do so, then it means the related entries won't work until you go back and enter it. If you enter the wrong value, you get the wrong results. There has to be a better way. Luckily, there is.

If you've been reading the blog for the last little while, you know that I've been hanging out on Plurk recently. Naturally, that means that I have been playing with Plurk as well, and trying to integrate it into my daily routine. When I used Twitter, it meant that I used Twitterfeed to create Tweets from the entries that I posted here. The problem is that Plurk has no such interface, as it doesn't have an API, so no such solution exists.

Luckily, Plurk power-user Ryan Lim came to the rescue. Not long ago, he released RLPlurkAPI, a PHP-based API into Plurk. It's not an official API, but it's good enough to allow outside services to access Plurk from the outside. It isn't Twitterfeed either, but what it did was allow people such as myself to see that it's possible to access the system from the outside. Unfortunately, I still couldn't do it, and I needed some more help.

If you read the post where Andy talks about releasing the Automattic stats plugin for self-hosted WordPress, he mentions a few things that make it interesting - notably that the system "only supports WordPress". Then he also mentions that anyone with a thorough understanding of WordPress and XMLRPC could clone the plugin to make it work with other platforms.

I don't claim to have such knowledge (of either WordPress or XMLRPC), but I think I've managed to do just that. Make it work with another platform, I mean. Some time ago, I managed to get the blog registration piece working, which really wasn't that hard - you simply pass some data to the system along with your API key and in return you get your blog registered. Not too bad. Then I ran into a speed bump of rather monumental proportions. Actually it wasn't that the bump was particularly large, it's that I hit it and then had about a million other things to do. So I put everything on the back burner.

Back in December, I put together a script for converting RightFields data to CustomFields. This was mostly for me, but I had a few people request this sort of thing, and I had grown tired of doing it by hand, since I'm inherently lazy. There were two problems with this script. The first was that it didn't do data stored in custom SQL datasources. Unfortunately it was just too hard to figure out. That's not to say that I couldn't make it work, but I wasn't able to do it in an automated fashion.

The second problem was that it left out a few people who had some data that they might want: Namely those with data stored in file fields (usually a file name, such as that you might use for an image). These fields can be somewhat complex, but if it's just a name, then it's not typically a problem in converting the data. So it may be okay to convert it. Still, you should probably be aware that a one-to-one conversion of this sort does have some potential pitfalls. The most common was that CustomFields doesn't have an upload option, but you also can't do things like extra file path information. So if you decide you want to convert the filename, you should be aware of these potential downfalls. It's better than nothing, however.