CiviCRM Community Forums (archive)

I've just been through the harrowing experience of moving a site from on server to another and upgrading from Drupal5/CiviCRM2.0 to Drupal6/CiviCRM3.0.

I had the pleasure of viewing many error screens throughout the process, googling the errors, and discovering that hundreds of sites have given up the fight -- they simply display their error page proudly.

After 5 days of hell, I realized that the only sure-fire way to make it all happen is a tiny 4 line note at the bottom of this page:
http://wiki.civicrm.org/confluence/display/CRMDOC/Moving+an+Existing+Installation+to+a+New+Server+or+Location

As it is the ONLY SURE-FIRE way to go through the process without errors, and as there are hundreds of sad, former CiviCRM users out their displaying 4 different error pages associated with this task, maybe someone should change the manual to help out the great-unwashed.

Move that 4 line paragraph to the top of the page, with a bit of expansion on the steps.

Explain that it is sure-fire, but there may be, perhaps, other 'easier' ways to accomplish the task -- and if you need an 'easier' way -- to read on down the page.

JJ

It was 5 days of pain. I can't remember it exactly...

But I was getting errors like these:

http://www.tribalbelly.com/
http://naturalfamilyhealth.org/
http://www.lapetabruzzo.it/

http://contact.aidconline.net/sitex/amandla-subscriptions
http://pro2-webbureau.dk/civicrm/ajax/jqState

http://brightworkcottage.org/index.php?q=civicrm/ajax/jqState
http://www.conf-irm.org/drupal/index.php?q=civicrm/ajax/jqState
http://www.pyper.ie/civicrm/dashboard?reset=1

And another one about CRM or something like that.

The only point I'm trying to make is that the manual isn't explaining things clearly, as you can see by googling the error messages. Too many people are giving up on their sites, and the manual is to blame.

If the only sure-fire way of doing it is way down at the bottom on the documentation page, people give up. It should be at the top of the page, not a last resort when people are so confused that they can't even read that far.

Another problem I had, that isn't clear in the manual page is that I went from 2.0 to 2.1. Well, it doesn't work, something is broken in 2.1. It took me hours to figure out that you need to go to the highest 2.1.x not the lowest 2.1.0. A sentence that 2.1.0 is broken would really help people out. Not sure which manual page that should go on.

Also not sure why this got moved from the Documentation forum -- because the only reason I'm writing is I think the documentation should be changed.

Moving locations can be a harrowing experience.  But I'm glad you persevered in the end.  I'm with Lobo though, the steps seem to work with `config_backend` = NULL for me, never had a problem past that point.  But if the instructions at the bottom seem to work well for your case, that's good too.   

IMHO, it's all about hosting.  If you have a reasonable VPS or dedicated CentOS system you are going to have a easy time moving stuff around.  If you have a restrictive or shared hosting environment, you are in for pain.

I'm not sure why Civi can't figure out most of these things itself, but I wrote a script that fixes this problem.  You need to edit the script to match your database and how you put your files on disk, but once you edit this stuff, you can run this sucker and all will be right in the world:
<?php
/**
         File:  fix-gammy-settings.php
 This is a simple utility to munge the settings object for
 civicrm, which unfortunately is a big blob of serialized
 PHP.  So we suck it out, munge it, and put it back shiny
 and new with the right parameters.

 To use this script, you need to edit a few parameters, including:
 
 * The database parameters for your local install

         * $files_dir, and $site, which depend on how you're
           installing on your local machine.


 Author: Rob Thorne, Torenware Networks
 Last Update: 12 June 2010

**/

//Obviously, if these differ for your database, edit the following:
$db = 'DBNAME';
$user = 'DBUSER';
$pw = 'PASSWORD';

## We want to move from the "global" files into a file dir
## that is in the sites/MYDOMAIN directory:
$files_dir = "/home/YOURACCOUNT/path/to/drupal/docs";

## We also want any resource fetches to get fixed.  The URL string
## should be relative to the civicrm install, which should always
## be in sites/all/modules for any DA install.
$site = 'http://your.domain.org';

## And we assume best practices: you should put your settings into a
## directory under sites/ named after the domain name you will use
## to access the server:
$settings_dir = "default";

$changed_keys =
array("uploadDir" => "$files_dir/sites/$settings_dir/files/civicrm/upload/",
      "imageUploadDir" => "$files_dir/sites/$settings_dir/files/civicrm/persist/contribute/",
      "customFileUploadDir" => "$files_dir/sites/$settings_dir/files/civicrm/custom/",
      "customTemplateDir" => "$files_dir/sites/$settings_dir/files/civicrm/templates_c/",
      "imageUploadURL" => "$site/files/civicrm/persist/contribute/",
      "userFrameworkResourceURL" => "$site/sites/all/modules/civicrm/",
      );



//In our database this should be unique, so we will only
//process the first record in civicrm_domain:
$fetch_sql = "SELECT config_backend FROM civicrm_domain";
$update_sql = "UPDATE civicrm_domain SET config_backend = '%s'";

//We call directly to the PHP APIs, w/o using Drupal's wrappers:
$link = mysql_connect('localhost', $user, $pw)
    or die("Could not connect to MySQL as $user: " . mysql_error() . "\n");
echo "Connected successfully\n";
mysql_select_db($db) or die("Could not select database $db\n");


//Get our domain record:
$result = mysql_query($fetch_sql) 
     or die('Could not fetch domain record from CiviCRM DB: ' . mysql_error());


     while ($line = mysql_fetch_array($result, MYSQL_ASSOC)) {
       $settings = unserialize($line['config_backend']);
       if (!$settings) {
 die("ERROR: Settings did not parse right; bailing.\n");
       }
       else {
 echo "Settings look legit; let's fix them\n";
 $new_settings = array_merge($settings, $changed_keys); 
       }
       $new_string =  serialize($new_settings);
print_r($new_settings);
       $query = sprintf($update_sql, mysql_real_escape_string($new_string) );
       //print $query;
       mysql_query($query) 
 or die("Could not update domain record: " . mysql_error() . "\n");
       //we will only touch one rec anyway
       echo "CiviCRM settings are fixed!\n";
       exit;
     }

?>

You run the script like this:

php fix_gammy_settings.php

and the script does the rest.

check bin/migrate/move.php

it figures out the differences and moves the db settings (in most cases) quite nicely

lobo