Technology and design in plain language.

If you don’t use Movable Type or either one of these plugins, you can stop reading now.

I hope you’ll forgive the long, intimidating title. It’s just that there has been some confusion regarding the move from Right Fields to Custom Fields, specifically when it comes to asset related fields.

First, let’s talk about the difference between the RightFields and Custom Fields image field.

A Rightfield’s file field let you choose a file from your computer. On save, this file would then be uploaded to a location on your server that you specified in the settings for that particular field along with miscellaneous upload options like naming and overwrite. Rightfields stored the preset upload folder separately from the entry filename. Then it offered a tag (i.e. <MTFileURLPath field="document"> which basically “built” your file’s location by combining the preset folder and the name it gave it when it uploaded. This was extremely useful because a developer could preset all of the location, naming and overwrite defaults and the client didn’t have to think about it.

Custom Field asset fields work differently. You click an “Upload” button which triggers the asset manager. All of the options for naming, location and overwriting are presented to the user through the asset manager interface. It’s a somewhat bulky process, especially for developers looking to streamline the image uploading experience for their users. The upside is that other plugins can manipulate the asset manager, like Dan’s Better File Uploader.

What’s the big deal about converting RF file fields to CF asset fields?

As was mentioned before, Rightfield separates the filename from the location. This dissection of the URL makes converting into a system asset a pain. Also, keep in mind RF really knew nothing about the asset other than it’s filename—it is, essentially, a textfield with the filename. So converting it to a text field in CF makes the most sense from an developmental standpoint. That’s exactly what Chad Everett’s RF2CF plugin does. Obviously, it’s not the perfect solution, but it works.

So, what should happen?

The ideal scenario would be for the import tool to merge both Chad’s RF2CF plugin with Arvind’s AssHAT plugin. This uber-plugin would pull out the file name from RF’s file field, combine it with the base location from the field settings and then pass that full file location information to AssHAT’s magic unicorns which could then turn it into an asset.

For right now, though, the best solution (which I’ve used several times with great success) is Chad’s plugin which ports over nearly all of Custom Fields successfully and puts the filename from old RF file fields into simple text fields which can then be built out into your templates.