Once upon a time in the Drupalsphere, there was the Image module, which was the preferred image solution for all Drupal sites. It dynamically resized images for display, so you could upload one image and get other sizes. But it was limited to one image per node, which made it hard for situations where you wanted to insert several images into one article. All kinds of workarounds emerged, but it was all a bit kludgey. It was nice to have something, but people were looking for something better. When Imagecache came about, it was received with much excitement, and it soon took over as the preferred image handling solution for Drupal, because you could attach several images to a node, and because it was much more performant and scalable. When Drupal 7 was in development, this functionality was considered so essential that Imagecache was incorporated into Drupal 7 core and renamed “Image”. (Yeah, it can be a bit confusing if you don’t know the history.)

If you were riding Drupal through those image solution shifts, it could be a bit of a rough go. In my upgrades over the years, I lost my Image node-generated posts. They were there from 2006-2007, but my upgrade to Drupal 5, when I adopted Imagecache for my images, left them adrift. I had figured those posts were doomed to obscurity, with no hooks to pull them out of database obscurity. Oh, you could see the text, but the images were gone. And if you tried to edit the node, you got no node edit form, just a blank page. I wasn’t going to try to fix that for a handful of posts. I figured I just had to write them off, sacrificed at the altar of progress.

I was wrong.

I recently discovered that this content loss due to Image module deprecation has a solution. When I first saw this, I guessed it was too late for me, as I should have done this in a previous Drupal upgrade, ideally when I made the initial jump away from the Image module.

But I thought, what the heck, give it a try!

Field Converter module

It was this module I found myself looking at that got me excited.

A framework for non-CCK modules to use to convert their Drupal 6 custom data to Drupal 7 FieldAPI fields….

…Currently, Image and User terms are using this framework to migrate their data to fields on Drupal 7.

Ooh! Maybe I can rescue my Image nodes after all!

I started digging around, and learned that there is really no documentation on this. You have to read the code and figure it out.

I went to look at the old Image module in contrib, where it said on the project page:

Upgrading … from Drupal 6 to 7: Image node data may be converted to Image fields using Field convert module; the image_legacy module (in this project’s git repository’s 7.x-1.x branch) provides the necessary field conversion information.

Nice! Obviously I couldn’t simply enable image.module, as it would conflict with the core module’s namespace. So I looked for documentation, but didn’t find any there, either. I explored the Image module issues, and found Image module migration, a critical open issue with lots of discussion on just this migration need. There I saw more mention of the image_legacy module, which, as it turns out, is a module within the Image module package. People were saying it was working, albeit with issues.

Hmmmm. I had the basic elements to give this a try. I made my backups and hunkered down in my dev environment for a potentially long session.

Image -> Imagecache -> Image

Because of the namespacing conflict, it makes sense that there is no Drupal 7 image module release. You have to check it out via Git. I did that. I used Drush to install Field Converter.

I enabled the Image Legacy module and the Field Converter.

And found nothing available in any menus or admin screens. Digging around the Field Converter code, I found:

<?php
function field_convert_menu() {
  $items['admin/content/field_convert'] = array(
    'title' => 'Convert fields',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('field_convert_select'),
    'access arguments' => array('administer software updates'), // @TODO CHANGE ME
    'file' => 'field_convert.admin.inc',
  );
  return
$items;
}
?>

That gave me the admin screen path (…/admin/content/field_convert), so I entered that into my browser toolbar, and a very simple screen with a couple of checkboxes appeared. One checkbox was for converting Images.

So I checked the box and submitted the form.

A few moments later, the process was done. Did it work? I went to /admin/content and found all my image nodes updated, with valid node type designations no less! The entire effort took me all of ten minutes.

Elbow grease required

When I looked at the nodes, though, the images were not there. However, when I clicked to edit a node, the form loaded, which itself was a victory, complete with the node body field, as well as the original image and two resizes listed in the File Attachments.

From there it was an easy manual remediation task:

  1. Load the Filefield Sources module, configure it to look in the folder where the old images were still residing.
  2. Edit the image node and mouse over the original image attachment link to see the actual image filename.
  3. Select that file from the Filefield Sources dropdown.
  4. Save the image node. The image was now there!
  5. Repeat for each image node.

And the cat blogging is returned! Since I had only a few dozen images, this wasn’t so bad. If I had hundreds, this probably would have been a bigger task meriting exploration of some kind of batch processing.

Thank you

My big thanks to joachim for the awesome work, contributing the code for the Field Converter and Image Legacy modules, sharing a workable solution for what seemed to be a problem with no easy answer!