upgrade

As mentioned previously, this site was recently upgraded from Drupal 6 to Drupal 7. Here's a more in-depth post explaining how I did it, and what the experience was like. Note that I use "upgraded", as distinct from "migrated", because I didn't create a brand new D7 site and push the content into it. For better or worse, I followed the actual d.o recommended upgrade path for major releases.

To avoid having to repeat the tedious work of database upgrades and code downloads, again and again for each different permutation of preferred modules, I used the drush site-upgrade command. I can really recommend it: while it's no silver bullet, it at least permits you to set a site upgrade running, then do other more productive tasks while it completes instead of having to babysit the process. drush site-upgrade very closely follows the Drupal 7.x major upgrade procedure described in UPGRADE.txt, which means that you can at least go through its output and dissect precisely what it was doing at each point.

Below, then, is my direct experience of the upgrade process: it hardly constitutes recommended best practice, as it does detail some of my slip-ups as well. If you're going to follow something step by step, then read UPGRADE.txt instead.

Before you start: just give it a whirl

Because drush site-upgrade takes away a lot of the pain of upgrading, and because it does so in a separate D7 instance that you specify with Drush site aliases, then it's tempting to just give it a try. I did, and I can heartily recommend doing so: it's the best way of discovering the biggest, most problematic hurdles between you and a D7 site.

I think in theory drush site-upgrade should upgrade all the modules in your D6 site first, before beginning on the major site upgrade. But you should also consider doing that yourself on your current site, especially as it's a (somewhat time-consuming) no-brainer that site-upgrade is always going to have to perform.

Running this command with no options means that Drush might request your input, so you probably want to babysit this trial upgrade and see what happens.

Preparing your site(s)

Along with upgrading all the contributed modules and core in your D6 site, you should also look at a few other tasks which the initial trial upgrade should have highlighted:

• Create an empty target Drupal 7 database. Unless you specify a particular configuration in your site alias for this, it will need to have the name "Site alias name with punctuation removed" + "db", and the same access credentials as your D6 website. My site alias was "@jps7.local", which meant that I needed a database called "jps7localdb".
• If you have any file include()s in settings.php, remove them or comment them out. This file gets copied over verbatim into your new D7 site, so it's possible that such includes will break. Not a serious problem, but it does make the upgrade output very noisy with unnecessary PHP warnings.
• Download and enable the schema module, and use it to fix any inconsistencies between the D6 database as it should be, and the database as it really is. If it looks like a load of tables have been left behind by a long-gone contrib module, download that module and explicitly uninstall it, as this will also clear up any system variables it might have set. Disable and uninstall it when you're done.
• Disable your custom theme. It's not essential, but having a custom theme did lead to some loss of themeing for me on my new D7 website, even though drush site-upgrade claims to downgrade the theme to core Garland.
• Disable and uninstall as many contrib modules as you can. Because my configuration was straightforward, I uninstalled the whole of Display Suite including Node Displays etc, because my trial site upgrade simply could not deal with it: there seems to be a relevant bug in the issue queue, but this was the easiest solution for me. I appreciate this was a pretty drastic move, but for a blog-based website I didn't foresee any serious consequences of redoing the DS configuration by hand. I also got uninstalled Image Gallery and CCK Redirection, although again this might be too drastic for your website. Remember to uninstall any helper modules: schema, as discussed above; but also devel, coder and any testing modules.
• Delete any content types you don't use. The same goes for any input formats, taxonomies etc: anything that you really don't need to migrate. If it has potential to break your migration, get rid of it now rather than later.

Successful (or at any rate completed) site upgrade

With the above changes made to the website, I ran drush site-upgrade @site.alias --auto. This extra flag means that the process runs with as little input from you as possible: in fact, assuming you've fixed any fatal errors mentioned above

This did mean that the following assumptions were made by the Drush command:

• I would fix any hacks to core (htaccess, robots.txt etc.)
• I would also copy across sites/files and sites/all/libraries
• The default CCK-equivalent modules in D7 were used: specifically node_ and user_reference, rather than entityreference.
• Automatic CCK field migration was performed on any fields that could be found, using D7's instance of CCK and the cck_migrate module. This migration of variable reliability, but improved by assuming the defaults above.

Immediate fixes on the D7 site

Once the upgrade happened, I concentrated on just getting a working D7 site with the content looking right to the site visitor. For that, I had to do the following:

• As mentioned above, my uploaded files and my libraries folder had not been copied over by the automated process, and I had to do that myself.
• My themeing was largely broken and CSS-free. This might have been because I was using the core Color module. Anyway, (re-)saving Garland's theme settings fixed it straight away. 
• To get Geshi syntax highlighting working again, I had to enable it on the text formats, and then administer Geshi and add at least one other language to the list of available languages. I think the latter is a minor bug in the CSS workflow of Drupal's geshi module.
• I also downloaded and enabled the media module and file_entity, sooner rather than later. To be honest, I couldn't tell you for certain whether this was a requirement of any of the procedures here as such. I just knew I was probably going to need something to manage documents and images.

This was the point at which I switched the codebases over on the live site, and my web presence was from that point on entirely in Drupal 7!

Improving admin and more niggles

There were still a few problems with the site; in fact, I'm still shaking a few bugs out now. None of them were really serious, but they did all have to be dealt with, and I did so as follows:

• I was using the image module for image management: I know, old-skool, right? This meant that to have my images managed and appearing in Media,  image nodes had to be converted to managed files. The field convert module helps with this; for a more detailed howto, read this excellent blogpost by Laura Scott.
• I lost my WYSIWYG profile for full text. I recreated this manually.
• Pathauto was failing because token syntax has changed radically (arguably for the better) but this was not migrated by the upgrade procedure. To fix, I manually edited the tokens to use the new syntax.
• My migrated images were managed OK, but the actual page for each image entity wasn't rendering the image. This was because each image's bundle type was set to "undefined" in the file_managed table. This was probably the worst problem to solve for anyone not well versed in databases, as it required a (relatively straightforward) SQL UPDATE statement.

Embracing Drupal 7

Finally, it was time to start taking advantage of some of the simplest improvements with Drupal 7. This included the following:

• Toolbar and shortcut module, to provide an "admin menu" experience across the top of the site
• Contextual links, for quick links to edit e.g. blocks on a page, or a view listing.
• An administrator role (under Configuration > Account settings), so that whenever a new module is enabled users with that role get all permissions for it straight away
• Update emails, warning me of important security updates, once per week (although all those decisions are configurable to taste)
• Media module, as mentioned above
• Views had automatically upgraded to version 3, which includes a huge and improving overhaul of the UI. 

There are a lot more improvements I can make going forwards, but this is where I drew a line under my personal upgrade project, and called it: success.

Summary

Upgrading a simple site from Drupal 6 to Drupal 7 is certainly comparable, if not preferable, to a content migration. The above took me around a working day and a half, split over a few nights. Personally, I can recommend it, as I felt at the end that, once everything had obviously migrated correctly, I had a very robust D7 setup.

Obviously if your site is more complicated, then automatic upgrading might be less straightforward. Almost certainly you'll need to keep Display Suite in place, which means solving the bug I encountered. And if you've got any custom code or (more likely) themeing, then upgrading this to work with Drupal 7's new APIs and themeing layer will not be at all straightforward.

But much of that would be the case whether you upgraded or merely migrated content. So do consider an upgrade: I found out from my own very meagre personal experience at the Drupalcon Copenhagen code sprint that a huge amount of work has been put into the upgrade path; it really seems to have paid off.

This site was quietly upgraded to Drupal 7, in stages over the course of the past few days. Well, I say quietly: it was pretty noticeable from my perspective. But hopefully nobody else realised that it was happening, or had suddenly switched; that was the point!

Partly in order to work out whether or not it could be done, I very purposefully did an upgrade of the old D6 site, and not a migration of the content into a new D7 site. It turns out that it could indeed be done, although I'm sure the simplicity of my site has a lot to do with that.

I'll do another blogpost in a few days, about how I accomplished it, but I'm waiting for the dust to settle, the bugs to shake out etc. Speaking of which, I'm off to check that this post appears in my RSS reader of choice!

The first stage of building this site was to import the content from the previous site. Well, the first stage was actually to set the site up: to install Drupal and enable the relevant modules. At Torchbox we've got a custom install profile that does a lot of this for us, installing and configuring relevant modules and creating users and roles. The actual company profile does a lot more work than I needed, in fact, and I've had to pare it back a little so that I've got less to maintain and worry about.

Importing content from Wordpress was largely handled by... the Wordpress Import module. There's a Drupal heuristic that, if it's a problem that a few people have encountered in the past, there's probably a module for it. Wordpress instances provide an XML export file called a WXR file, which you put on the filesystem and the module can convert content, freetext tags, the category hierarchy and users/authors.

The one tweak I had to make to the module was required to import the article summaries or excerpts, the little "humourous" quotes that are intended for blog listings. These were present in the WXR file as the <excerpt:encoded> element, and the Wordpress Import module contains a nice utility function that meant I only had to add this code at around line 621 to bring in the excerpt as a CCK field:

$node["field_summary"][0] = array(
  "value" => wordpress_import_get_tag($post, 'excerpt:encoded'),
  "format" => $params['format'],
);

Overall importing from Wordpress was pretty smooth---thanks to both Wordpress and Drupal, to give both technologies their due---but having content on a beta site is a double-edged sword. It's great to be able to see broadly how the site is going to look when it goes live, with everything in place; on the other hand, it's disappointing to be able to see broadly how the site is going to break when it goes live. Content showed up all sorts of little bugs: missing, slightly quirky CSS formatting you'd forgotten about; oversensitive output filters; slightly wonky imported URL aliases that needed a visit to the database to fix.

As I iterated and tweaked the configuration on the Drupal site---with content already in place---I had effectively frozen the site development, and could no longer roll back and re-import as it would lose my configuration changes. The import itself meant that for a week or so I was running two sites in parallel, writing blogposts on both, and getting a bit flustered about it all.

I think it was the right, pragmatic decision to do that, even though it initially felt like a lot of overhead: writing some sort of module to do the configuration changes was possible, but didn't really suit the way I wanted to fiddle with the site rather than run a set of fixes; importing at the very last minute would have meant I'd not have found most of the little irritations until they were publicly visible; not putting content on the blog for a week wasn't really possible, what with Oxford Geek Night 14 rumbling on, and our most excellent sponsors all clamouring to give us stuff. I just wish, as always, that I'd had twice as much time to do it all in.

Graceful Exits has just been upgraded to use Wordpress 2.7.1, so please let me know if you see anything amiss.

Incidentally, when I upgraded I saw some evidence of the wordpress.net.in injection attack in some of my files: I don't think it worked because of the way that the straightedge theme is set up, but it's not clear yet. If you've not upgraded to 2.7.x yourself, you should look out for that attack in your own code.

I finally began to get on top of Wordpress upgrades a few months ago, with an upgrade to 2.5.1. It worked well, but left me open to what looks like a failed attempt to exploit a cryptographic splicing vulnerability in Wordpress 2.5.x. I'm still checking database tables now.

In the mean time I've finally followed Tom's advice (which I didn't take when he volunteered it at the time) and upgraded Wordpress to a subversion checkout of 2.6+ . It was no more painful than the previous upgrade, and looks like being a much simpler procedure in future owing to subversion's interface for switching versions.

In brief: the problems discussed here and here go away under the most recent Ubuntu release, Hardy Heron, which I can generally recommend.

Alsa seems stable and graphics support is present from installation onwards. Enabling fancier 3D compiz effects requires the nvidia-glx-new package; compiz spots this, however and prompts for installation. All very smooth. Wireless works; my VoIP headset works; but I haven't yet tested Bluetooth.

The only problem was in upgrading from Gutsy: my previous peregrinations had rendered my hybrid distribution shafted and incapable of upgrade. This isn't a problem, though, if one has installed the /home directory (and in my case the /music one too) on a separate partition: the Ubuntu Live CD will blat the root partition with Heron, but leave the other partitions alone if you so require. Don't resize any of your partitions during installation, though, or you'll lose everything. Everything!

After having been stuck on version 2.0.1 for over two years, I’ve just upgraded to the most recent version, 2.5.1. The only hiccup was needing to ask my web provider to give me a new MySQL database: since 2.5, Wordpress has required MySQL 4.0 or newer.

Otherwise, it all seems to be running very smoothly. Do let me know if you see anything crazy. I hope to upgrade more frequently in future, as it was a far better experience than I’d expected.