Getting Forked

Since last weekend, I spent my evenings manually moving content on deninet. It many ways, it was an exhausting process, but it gave me something to do while I suffer through the last two seasons of Star Trek: Voyager. Let me chart how I arrived at this point.

Over vacation time in December, I decided to conduct a little experiment. I would attempt to upgrade the current deninet website from Drupal 6 to Drupal 7. When I had attempted this a year ago, it did not go well. The upgrade process crashed spectactually, leaving me with a lump of a database. Thankfully I was doing this on a local copy, and not the live site. I had speculated that in the interviening year, Drupal would have ironed out a lot of the edge cases I originally ran into. So, I copied off the site and tried again. To my astonishment, it worked.

This created a dilemma. The previous year I had created a new deninet website by manually copying content from the version based on Drupal 6 to the new one based on Drupal 7. When all the features I needed to run the site were available, I'd switch to the new site. I had maintained the D7 fork from time to time, manually importing nodes and to make sure the two sites where in sync. At the time, this seemed the best way to go. I would lose things like comments and break all the URLs, but the end would be a good move.

Except that the new site never seemed to get anywhere.

I had reservations about the URLs and the comments. While I could bury my feelings, claming it was for "the greater good", it still bothered me. There was the bigger issue that I really wasn't getting anywhere with the D7 site. It sat and languished, while I couldn't resolve the issue.

After successfully upgrading the site, I began to wonder if I could take a more fluid approach. I used Pathauto to create URLs that would be the same for both the current D6 site, as well as a D7 site -- upgraded or new. The biggest problem was images.

Currently, the D6 site uses a method of posting images (image.module) that will not work when upgraded to Drupal 7. The resulting content would have no content type, and the references to the image files would vanish. In order to fix that, I would need to find a way to move that content from image.module to imagefield. Imagefield is the preferred way to host images on a Drupal 6 site. While image.module was compatible, there was no easy way to migrate between the two.

Assuming the worst, I expected that I would need to manually move all the images over to something that would work. I modded the Blog content type with Imagefield, and set to work. If a blog post referred to an image, I would edit the post and attach the file, editing the HTML in the process. If no blog post was associated with the image, in many cases I created a completely new, but backdated blog post containing the content.

It worked, but it had problems. Images had no means to be scaled automatically. If comments were made on the image itself, those were lost in the process. Again, URLs were broken. I tried telling myself it was for "the greater good", but the results felt wrong. I had discarded much of the meta-data associated with the images, breaking links along the way.

So today, I decided to try something else. I found a script online that promised to convert in place all of those old image.module nodes to D7-compatable imagefield nodes. I prepped a local copy, and set off the script. From all appearances, it worked! Unfortunately, all of the blog posts that relied on the old image.module stuff now had broken images.

Damned if you do, damned if you don't.

Fixing the links to the images in the blog posts wouldn't be too difficult. I would be able to get the content to a usable state with another week of evening edits. Even if I do this, I'm unsure if the D7 upgrade will take. Still, at least I'm getting somewhere.

drupal