How I upgraded CiviCRM 3.4 to 4.1 and Drupal 6 to 7

Note: A comment below says that this procedure does not work for upgrading from 3.4 to 4.2. (Thanks Paul!)

The path I took was

  1. Migrate my site to a test server
  2. Upgrade CiviCRM from 3.4 to 4.1 on the existing Drupal 6 site.
  3. Upgrade Drupal from 6 to 7 while simultaneously updating the CiviCRM codebase for Drupal 7

I found lots of pages on CiviCRM's wiki about various upgrades, but apparently one's not been written for the upgrade of D6 to D7. So thought it would be worth sharing this.

Migrating to a test server

Believe me, you need a practise run at this upgrade, but even this first step is ridiculously fiddly!

As you'll see from this 1,500 word wiki page it's not simple. In the end I sort of found my own way to do it and wrote a script to make it (slightly) easier.

Upgrading CiviCRM from 3.4 to 4.1

CiviCRM 4.1 has two versions, one for Drupal 6 and one for Drupal 7. There's a constant, CIVICRM_UF, in the civicrm.settings.php file that needs to be Drupal6 for the drupal 6 version, and just Drupal for the d7.

I mostly followed the instructions except that you need to ignore the big red warning at the top that tells you "Please modify civicrm.settings.php" because while you do need to do it, if you do it first you'll get nowhere. It tells you when to do it later on.

Upgrading to Drupal 7

I mostly followed the instructions on Drupal.org but with a twist. Here's what I did

  1. Logged in as admin.
  2. deleted sites/default/default.settings.php
  3. moved the sites/ folder (and my other folders, e.g. I use a civicrm_customisations folder) out of the way.
  4. deleted everything in the webroot folder(!)
  5. Downloaded and un-tarred the latest Drupal 7.14 (well, I cloned it from git).
  6. Brought back in my sites folder, overwriting any files therein, with  cp -ar /path/to/old/sites ./
  7. Edited sites/default/civicrm.settings.php and changed Drupal6 to just Drupal
  8. Deleted sites/all/modules/civicrm
  9. Downloaded and unpacked CiviCRM 4.1 for Drupal 7 into sites/all/modules
  10. Visited http://example.com/update.php

Comfortingly, this last step brought up Drupal's lovely updates interface with 128 updates required, and sure enough one of them was to do with CiviCRM - great!

This ran through smoothly. Yippee.

Fiddles and the last remaining niggle

A lot gets unbroken by visiting, checking and submitting the forms on these pages:

  • civicrm/admin/setting/path?reset=1
  • civicrm/admin/setting/updateConfigBackend?reset=1

And by rm -rf sites/default/files/civicrm/templates_c/*

The last thing I'm stuck with is that Contact pictures are still failing to load - the PHP is calling getimagesize() but using the old URL! I haven't found where this is stored yet (or why it's not updated with the path/updateConfigBackend wizardry). If you know, do leave a comment :-)

 

Access Control: 

Comments

Great stuff, I'm going to be trying this myself next week, so thanks for sharing. The image url is rubbish; it's stored as an absolute path in the image_URL field in the civicrm_contact table, and I don't think there is a way to regenerate it. In the past I have run SQL updates to replace the old "http://www.oldsite.com/images/foo.jpg" with the correct "http://www.newsite.com/images/foo.jpg".
<p><strong>Ah, thanks!</strong> Yes it was driving me nuts. That is surely a daft way to store an image reference. But CiviCRM <em>is</em> getting better (I think) at doing less of this - absolute URLs used to be <em>everywhere</em>!</p>
Beware!! These instructions do not work for going from 3.4 to 4.2. You end up with Fatal DB error, exiting, seems like your schema does not have civicrm_setting table Sadly, I guess you have to upgrade to 4.1 first or do a fresh install to get that table. Though, I see things on the forums where people had issues with this table going to 4.1.something.
@Paul - thanks for that, I've put your warning at the top of the post.

Add new comment