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.

When Six Apart released Movable Type 4.1, with it they released an entirely new commenting architecture. And technically, the foundation was laid with

With version 3.31 of Movable Type, the product began shipping with feeds.app lite, which allowed some simple abilities for republishing the content of other feeds on your site, through the use of Movable Type template tags. This plugin was a great step forward, and expanded on earlier plugins that did similar things, but in fact, it is the less-capable sibling of the (much) more powerful feeds.app from Appnel Solutions.

The primary difference between the two is that feeds.app lite allows you to pull some basic information out of the feed, while feeds.app allows you to get anything at all - it's much, much more powerful (and it also has a price tag associated). Unfortunately, feeds.app, while insanely powerful, also has caused some signficant hair-pulling to get things working from time to time. It's a shame, because it's a good plugin. Some of the problem is a conflict between the default feeds.app lite plugin and the full-featured feeds.app plugin. Some is that there are a lot of requirements (that ship with the plugin), and it appears that many systems just don't support everything that you need to get it working. Because of that, I have recently been looking for an easier solution, and I think I've found one in Feed Digest.

One of the more challenging pieces of the Movable Type administration interface in version 4 is the syntax highlighting when you are editing your templates. That's not to say that the highlighting is entirely bad, because it can be nice, and brighten your day. Rather than having a plain old black and white text box, you get colors, and line numbers, and it does make things work a bit better. In 4.0, however, you had problems with cutting and pasting. Though improved in 4.1, there are still some problems - notably slow load times.

While you can disable the syntax highlighting (known as CodePress) by clicking on a button, the problem is that the script still loads and processes the data on-screen before disabling the editor, meaning that load times can still be slow. What's worse is that the preference is stored in a cookie, so if you're on another computer, or if another user logs in, the highlighting comes right back. Because of this, I've seen repeated requests on disabling the highlighting permanently. Unfortunately, you can't just remove the codepress directory or you'll get an error and be unable to edit your templates at all. Luckily, there is a solution.

Much of today, twitterfeed has been down. Which is okay - it just means that my blog posts don't get into my Twitter stream (just one of the reasons I don't like depending on third-party services). Last week, John Chow announced that he had set another new record, with more than $30,000 in income. Unforunately, if you haven't read the report, you may not be able to do so, because his site has been responding horribly of late (at least for me). I don't know what's happening for John - if it's a problem with his server, his software, or if he's just bogged down because of the latest numbers.

Frankly I don't care that much because I keep up with his blog through Google Reader, so I don't often have cause to visit. I only happened to notice that things were slow when I went to look something up, and realized that it had happened last week when I did it as well, so it seems to be an ongoing issue. Or it could be related to my own ongoing issues (but I don't really seem to have much of a problem with other sites). Whatever the case, it underscores the importance of keeping your site running.

To build a community, you need your visitors to comment on your site. Unfortunately when you do that, you open up your site to others who you might not want to come calling - namely spammers, who will leave all sorts of garbage on your (virtual) doorstep. While we probably won't ever be able to get rid of them, managing spam feedback is a completely bearable process.

Depending on who you ask, you're likely to get a wide variety of answers on the best avenue to take when it comes to plugins to use or configuration directives to take in the fight against spam. You'll see names like Akismet or Defensio mentioned, and plugins such as MT-Approval and Tiny Turing thrown into the mix. Some will tell you that you need a CAPTCHA and some will tell you that there's just no way to win. In the end, you don't really need much more than a little creativity and some patience.

One way to keep visitors involved in what's happening with goings-on at your site is by involving them in what's happening, and one of the more interesting developments in this area is by providing them with the ability to rate your content. Until now, one of the more common ways of doing so for Movable Type was with the Ajax Rating plugin.

Mark Carey has done a great job of putting the plugin together, don't get me wrong. But installing the plugin and getting it to work right can sometimes be a bit more than most folks want to take on. The advantage is that you get complete control over what's happening. Sometimes, however, you just need a quick-and-dirty rating solution, and that's where Outbrain comes in.

If you use Movable Type, there's a good chance that you use plugins. And if you took the plugin survey, there's a good chance that you use a plugin to add extra fields to your installation: Roughly one-third of people polled used either CustomFields or RightFields to provide some additional breathing room in your installation.

To make matters more interesting, the combined plugins accounted for roughly a third of the votes for being rolled into the core package, and easily bested all other plugins when it came time to choose just one plugin to install. The problem all along has been that there are two ways to add extra fields to your site. The announcement that CustomFields is now going to be part of Movable Type just makes it more complex - especially if you're a user of RightFields. Until now.

I haven't done a lot of work with Apache Tomcat previously, so when someone asked if they could install Movable Type, I had to do a bit of digging to see if it was possible. The answer is actually yes - but it's not the most intuitive installation. Most steps are fairly simple, but making the pieces work can be challenging.

Getting Perl up and running under Tomcat isn't difficult - just dropping the files into a directory seems to make them work. But to make Movable Type work, you need more than just Perl - you need MySQL. That's where the trouble comes in and things get a little dicey.

Over on Learning Movable Type, Jaclyn asked why she wasn't able to get tags imported to a new MT4 installation. While Movable Type 4 includes an entry's tags in the import specifications, and also exports those tags when saving the data, no prior versions have exported the tags, even though tags have been natively supported since MT 3.3x. Luckily, it's easy to get them.

First, make a backup of ImportExport.pm from your original Movable Type installation, which is the Perl module that handles the export. Do this because you want to make sure that you have a good copy, just in case something goes awry. Put this backup in a safe place, and work with the copy of the file, just in case. Ready? Good.

As is fairly common, there has been a good amount of talk about how blogs manage to scale recently, and what has been interesting to see is the discussion around just what it is that is required to keep things running.

Let's assume that you've decided not to go with a hosted solution, so first you'll need a good host, and you should consider some other issues about setting up your domain too. After that, you'll need to choose your blog software.

There are what seem to be thousands of choices, but ultimately it boils down to two: Movable Type and Wordpress. Tim, among others, likes to post pictures of Wordpress failing, but what isn't often mentioned is that Movable Type can fail in the wrong situations too. Let's see why.

If your Movable Type installation uses extra fields and you want to use MT4, then at this point, you really only have one option - Custom Fields. The plugin, currently in something of a perpetual beta because Arvind is in the US for school, allows you to easily add fields to just about any object in the system. It's actually quite nice.

But if you have already been using Custom Fields, you might find yourself in a bit of a pickle when it comes to upgrading your data and you've found that the data you have been trying to keep from losing is suddenly no longer there. Luckily, the upgrade path isn't a bad one, nor is it particularly painful. You just have to be very careful when you decide to upgrade your installation.