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.

It's really not difficult to transfer data between the plugins, though it is a rather manual procedure, involving the setting up of the new fields in CustomFields and then writing a small script to transfer everything for you. In fact, if you look hard enough - which is to say run a search here or there - you figure out how to do it relatively quickly. But up until now, there has been no automated way to do it. Now, that all changes.

I have put together a plugin that will do everything you need and transfer your RightFields configuration and data to CustomFields - all automatically, with little user intervention. It does require a bit of work, but it's a whole lot less than it used to be. First, a few disclaimers.

It cannot transfer linked entry and file types, because those are not supported in CustomFields.

It does not transfer system-wide settings, only those at the blog level.

It does not transfer your template tags (though you can update them later).

It does not transfer data from custom datasources, only from PluginData.

Unfortunately, there are no warranties express or implied with this conversion. Every attempt has been made to make it easy to use and make sure that it works as advertised. But as with any data utility, you should make sure you have good back up copies of your data before beginning anything of this nature.

Now, with all that out of the way, there are a few things you need to do.

First, of course, you need CustomFields. This process should actually work with any of the MT4-compatible versions, including the beta versions. But it has only been tested with the version that comes with the newly integrated addon version of CustomFields. Consider yourself warned.

Next, you'll need the plugin, creatively called RF2CF. You can download it here. This is not much more than a wrapper, but it's what makes everything work easily and simply. Once you download it, you want to unpack it into your plugins directory, where you'll have an RF2CF directory. Make sure to keep the directory structure intact, as there are some other folders underneath this one. There will be more in a minute, but you need one other piece first.

Finally, you'll need RightFields. As you probably know, RightFields doesn't work with MT4, so you don't want to install it in your MT4 directory. In fact, doing so might make everything blog up. But you want to take the lib directory and copy it over into the RF2CF directory. You'll end up with these files:

MT_HOME/plugins/RF2CF/RF2CF.pl

MT_HOME/plugins/RF2CF/lib/RightFields.pm

MT_HOME/plugins/RF2CF/lib/RightFieldsApp.pm

MT_HOME/plugins/RF2CF/lib/RightFieldsObject.pm

MT_HOME/plugins/RF2CF/lib/RightFieldsPseudo.pm

MT_HOME/plugins/RF2CF/lib/MT/Object/Pseudo.pm

MT_HOME/plugins/RF2CF/tmpl/blog_config.tmpl

MT_HOME/plugins/RF2CF/tmpl/dialog/config.tmpl

MT_HOME/plugins/RF2CF/tmpl/dialog/data.tmpl

Now, you can go into your plugin settings at the blog level. As mentioned above, there is no transferring of data at the system level. This is intentional. If you need to transfer any system-level data, simply set up your system-level fields and then go to the blog level and transfer data. This is because no data is stored at the system level, so writing a transfer routine just for that configuration wasn't worth the effort. Sorry.

Step 1 is where you transfer the configuration data. Two types of fields will not transfer: Entry Link and File Upload. This is because CustomFields doesn't support these file types. Also, the Key-Value Pairs will transfer over as valid options, but they won't work like they did, but you'll want to update them later. Do not run this step more than once per blog or you will create multiple instances of the fields and that can get messy.

Step 2 is used to actually transfer the data from RightFields to CustomFields and you can run it as many times as you like for each blog. If you have a lot of data, it might look like it is not doing anything, so keep an eye on your status bar. This is because the entire script runs before it outputs data. This just has to do with the way that the template displays and everything should be fine.

Step 3 is a maintenance step and allows you to review your CustomFields configuration (you can get there through the normal link as well - it's just there for convenience). Because the template tags do not transfer over, I would suggest reviewing your configuration and updating template tags if you need to do so.

Because the template tags used by CustomFields are vastly different than RightFields, you will need to update your templates. That is beyond the scope of this plugin. It is designed simply to make your data accessible, not to update your templates. Don't forget to update your templates!

And in case you're wondering, the CustomFields addon/Professional Pack will work in MTOS. You can even install it in MT 4.01 and transfer your data. I can't vouch for everything else working, but you'll definitely be able to get this plugin to work to move your data over.

You Might Also Be Interested In Reading:

Converting RightFields to CustomFields, Now with SQL Goodness!
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...

What to Watch Out for When Upgrading Custom Fields
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...

Structured Blogging and Right Fields
Recently we've seen the introduction of a couple new additions to the stable of Movable Type plugins, with the pre-release of the Structured Blogging plugin and the beta release of the RightFields plugin....

MT-Moderate 1.1.0
After extensive testing, and some excellent help from Iain and Kate, I think we've licked the problems under Windows servers. The problem has to do with the way that Movable Type handles the path when processing plugins. MT-Moderate and some other plugins use a new technique known as...

MT-Outliner 1.0.0
MT-Outliner: Access information from OPML files through template tags. A Plugin for Movable Type Release 1.0 October 6, 2003 http://www.everitz.com/mt/outliner/ If you find the software useful or even like it, then a simple 'thank you' is always appreciated. A reference back to me is even nicer. If you...

Comments (10)

This sounds great, but I use RF for uploading images and then use the RF tags to format the images in my posts. Sound like CF won't do this (no file type fields), right? How does the MT4 asset management features compare to this?

My use of RF has prevented me thus far from upgrading to MT4 so I haven't played with it yet.

Unfortunately, I don't use either RF's file option or assets. I don't actually use MT4 yet, as this was the first step of the transition. Now that it's done, I'm going to convert things over to MT4. So ask me in a short while.

But I suspect you can probably do most things you want with the asset system - and the whole point of this is to allow you to upgrade from RF to MT4 with CF. Or you could wait a few days - I understand Kevin is close to announcing a release for RightFields in the next few days.

Hi, Great tutorial!
I was waiting for the developer of RF to release a new version, but I hear no news about the development, so I decided to transfer to CF.
Since MT4.1 is ben released I was wondering if the same directions will still apply for the conversion?

So I tried converting RF to CF on MT4.1 (CF natively supported), it works but some features on 4.1 doesn't work. On Custom Fields under preference all the converted fields from RF shows up in a list and applying the tags to the templates also works fine.

One of the thing which it doesn't seems to work is when I try to click on the check boxes in the preference where you set which field to display whenever you create a new entry and save the setting, the checked boxes gets unchecked automatically.

The custom fields newly created on MT4.1 would check the boxes fine after save and shows up in the field with the new entry page, but only the converted fields from RF doesn't show up by default.

I would like to try the tutorial on MT4.0 and see if the same problem occurs, but sixapart doesn't provide 4.0 any more and I am stuck. I know I'm asking too much but is there anyway you can check up on this problem? Thanks.

Sorry for the delay, for some reason I wasn't notified of your comment!

I'm not sure what you're asking, exactly - sounds like the display of your Custom Fields in the entry display screen. If you need that, just check them and save the preference. There's nothing in the conversion that saves that automatically - to do it would require too much work, since it's a by-author preference, and looping through each author to save it wouldn't really be pratical. Just go into the entry, save your preference and you're set.

Hi Chad-
Thanks for the tutorial and the code; it set me on the right track for doing my own conversion from RF to CF. However, I was using an SQL table to store RF data so I had to add some code to manually connect to MySQL database. I basically only ended up using the skeleton of the rf2cf_data function from your code.

Would you mind if I posted the revisions I made on my Web site? (http://www.ryanpfister.com) I think it would help others in the same boat. I'd give you credit for the original code, of course.

Hi Chad - well done for writing this plug in - its really useful. I've just got one issue. I try to run step 2 and after 30 seconds I get an Internal Server Error. I've checked the permissions and they are 755 and can't think of anything else. Strangely, some of the tags have ported over. Any ideas? Anyone else had this? Thanks!

Usually if you get a 500 error after a while like that, it means that it's a server timeout. Unfortunately there isn't any (easy) way to process only a small chunk of data, which means that you could look at increasing the server timeout as the fastest way to alleviate the problem. You could also just run it again (there isn't a problem with doing that).

If you feel like mucking about in the database, you could get rid of data that has converted, if you know what has been transferred over (you could look at entries to see - take a look at the records, they are processed in numeric order). But you run the risk of losing some data.