Important
This article is from 2012 and a lot has changed in CiviCRM since it was written. Some useful comments below:
- Paul says that this procedure does not work for upgrading from 3.4 to 4.2. (Thanks Paul!)
- Sophie says you have to go to the latest 4.x via a stop-over at 4.1, which introduces a security bug that won't be solved by then upgrading. Please see her comment. (Thanks Sophie!)
Original article from 2012
The path I took was
- Migrate my site to a test server
- Upgrade CiviCRM from 3.4 to 4.1 on the existing Drupal 6 site.
- 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
- Logged in as admin.
- deleted sites/default/default.settings.php
- moved the sites/ folder (and my other folders, e.g. I use a civicrm_customisations folder) out of the way.
- deleted everything in the webroot folder(!)
- Downloaded and un-tarred the latest Drupal 7.14 (well, I cloned it from git).
- Brought back in my sites folder, overwriting any files therein, with cp -ar /path/to/old/sites ./
- Edited sites/default/civicrm.settings.php and changed Drupal6 to just Drupal
- Deleted sites/all/modules/civicrm
- Downloaded and unpacked CiviCRM 4.1 for Drupal 7 into sites/all/modules
- 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 :-)
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".
Ah, thanks! Yes it was driving me nuts. That is surely a daft way to store an image reference. But CiviCRM is getting better (I think) at doing less of this - absolute URLs used to be everywhere!
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.
Hi! I have used this procedure on a couple of websites now; and I found a few things:
The first site I did it for , I was unable to update to 4.2; but I was able to 4.1 using the directions. However, the second site I did this for, I HAD to upgrade to 4.2.10; (trying to upgrade to 4.1 gave me the 'you have no civicrm_settings table' error).
You definitely have to: 1) clear drupal performance cache 2) clean out your templates_c 3) remove all your old d6 modules from sites/all/modules
Beware of this vulnerability in CiviCRM in versions prior to 4.2.6: civicrm.org/blogs/totten/advisory-openflashchart-attacks .
Since you have to go to 4.1 before upgrading to drupal 7, and only then upgrade to the latest version of CiviCRM, you have to make sure to delete the file:
rm drupal/sites/all/modules/civicrm/packages/OpenFlashChart/php-ofc-library/ofc_upload_image.php
Obviously, when the advisory first came out, I deleted the file from the 3.x version that I had. But it fell off my radar during the upgrade process and I got burned.
Thanks for the blog post. It was very helpful.
Add new comment