This site has been upgraded to Drupal 7.
The notable pain points were:
- Choosing a new theme, since Antsin's BlogBuzz isn't available for D7 (yet?). Clearly this pain point is so great that I'm using the default Bartik. :-)
- Having to redesign the mile 23 marker slideshow at the top of this page. If you're using Views: Consider carefully how your upgrade path winds back and forth around rocks and trees.
- http://drupal.org/node/933498 (see below)
Using SequelPro I made a MySQL dump of the hosted mile23.com database. I pulled that into a new database in MAMP, again with SequelPro.
I thought I'd use Coda's Site feature to synchronize the files between mile23.com and my local copy, but it turns out Coda only goes one-way... You can't pull the files from the remote site, only upload (they call it 'publish') the files, or 'reverse publish' one file at a time. Coda uses sftp to do all this, so it's fairly easy to drag and drop all the files where you want them, independent of the Sites feature, but I was a little disappointed that I couldn't just set it up and press a button.
If I were really some kind of super-genius, file sync would have happened via git, and a private GitHub repository, but alas no.
Now it came time to prune unused modules and themes, and turn off all the non-core modules I wanted to keep. Some of these modules I set up years ago, and didn't really take notes, so there wasn't a lot of context. Some of them I had enabled experimentally. Some seemed super important at the time, but not now. (Fivestar? no one visits this site anyway...) I'm considering writing a module that lets you keep track of these things.
But the point here is that most of the modules (image_cache, for instance) were rolled into core for D7, so it was easy to weed them out.
The only real trouble with the core D7 upgrade was this: Image effects table created with incorrect table name in upgrade path. It's the sort of thing that would, as an old acquaintance would say, make the baby Jesus cry. A typo in the update function. Easy enough to fix with some SQL-fu (just rename the table from image_effect to image_effects).
After rearranging a few blocks and other minor tweaks, it was time to tackle the slideshow. A quick Google search later, this page provided the proverbial oil to the rusty gears of my Views knowledge, and reminded me why fields are the greatest thing since sliced bread. Well, maybe sliced bread is better, but yah.
I mentioned above that image_cache was rolled into core. This means that all my images were now in places that Drupal didn't expect them to be. I'm sure there's a smarter way, but since the slideshow doesn't have too many images, it was easiest to just create a new content type and re-upload them.
Time to go live....
I created a new directory on my server, called 'drupal7' (instead of just 'drupal'). Added a new MySQL database. Transferred the files, exported my local database, imported it into the one on the server, changed settings.php. Log in to pair.com and tell my domain to point to drupal7 instead of drupal. And a few minutes later, joy.
Except for the minor problem of permissions for the files directory, easily fixed. Again, a Drupal ninja would have a deployment script that would ensure all this stuff was right.
So now this tiny web site has the super-sophisticated izness that is the Drupal 7.