Coping with change

Printer-friendly version

A decade ago, I hosted a website for my partner, so that she could post photos and such for her family to see. She didn't use it much, and, in 2017, the hosting software reached end-of-life. So, I shut the site down, planning to upgrade the software and resurrect the site later.

Well, life got in the way, and I never did resurrect the site. Until now.

All my sites use Drupal. When I shut it down, I could not migrate the site in question to the then-latest-stable version of Drupal. The site used a 3rd-party module to host and present the hundreds of family photos my partner had published, and the new version of Drupal did not support that module. So, I shut down the site until I could think of a way to recover and present the photos under the version of Drupal I had moved to.

Fast forward several years, and the version of Drupal that I currently use is nearing it's end-of-life. As is the next version of Drupal. I have to migrate my sites two versions of Drupal this year. And that means that, if I want to re-launch my partners site, I have to migrate it to the same version of Drupal that I use for all the other sites, otherwise I can't migrate it to the latest-and-greatest Drupal at all.

So, this past week, I undertook that migration. I backed up the database and all the files, and "restored" them to a working-copy area. This left the original site's data intact, and allowed me to fiddle with the migration without damaging the original site.

With the copies in place, I performed the standard migration from one Drupal version to another. Successfully, for the most part; the photos, while still intact, didn't "migrate". There was no easy way to get them over into the new Drupal; I would either have to hand-enter each photo into the new website, or write my own "one-time" loader. A very quick calculation told me that I would spend more time hand-entering the photos than I would writing, testing, debugging, and using a one-time outside-Drupal migration script. So, that's what I did; I wrote, tested, debugged, and used a one-time script to repopulate the Drupal databases with the image pages that it needed.

The script evolved into three parts:

  1. Read through the old Drupal tables to locate the information on each image the old site had stored,
  2. Use that image data to relocate the image files to the place where the new Drupal wanted them, and
  3. Use that information to build new database data for each relocated image.

The first step was relatively simple; a few SQL queries later, I had a list (and corresponding layout) of all the tables the old used to store image metadata. I wrote a query to retrieve the essential information, like the filesystem path to each image, and the "taxonomy" term that the image used as it's "gallery" key. I could feed this list into the next two parts of my home-brew migration process.

The second step was to take each entry in the list, locate in the filesystem the image it related to, and copy that image to it's new filesystem home. Simple enough; just a "ln(1)" for the image and (for the thumbnail) a call to ImageMagick's "convert(1)" utility. Easy-peasy.

The final step was to take each entry in the list, and some image data (width, height, and filesize) from the image itself, and build the appropriate rows in the various Drupal tables. Not so easy, as none of this is explained unless you deep-dive into the Drupal developer site. But I am nothing if not resourceful. I created a single image entry in the new site, using the web tools that the website provided. Then, I ran many SQL queries to isolate the tables, and the rows that this single new image affected. I found 13 tables that, in some way, needed to have image information. A bit of study, and I managed to discern the relationship between these tables, and between the columns, and locate the data that I would need to fill in. The code of the final step populated each of these thirteen tables with the relevant data from the previous two conversion steps, and some constant values that would keep everything consistant.

I backed up my working-set (again; I backed up frequently, and "recovered" a few times as well), and ran the three conversion steps. And, out came a website that could properly display all of my partners photos. One more backup (so as not to lose the success that I had achieved), and I moved the new datbase and filesystem into "production".

The website underwent it's rebirth yesterday, three days after I started the conversion effort.

And, now I get to do it all over again (times 4 sites), for the next two versions of Drupal. Ain't I lucky?