CiviCRM Stack Exchange is a question and answer site for administrators and users of the CiviCRM Constituent Relationship Management software. It only takes a minute to sign up.
Sign up to join this community
If I restore a backup of a site with CiviCRM onto another server it seems that it does not work. Getting it to work is especially troublesome if I restore to a different operating system (Linux -> MacOSX, e.g.), but also differences in server setup seem to be problematic.
Is there a way that always works?
There are multiple "gotchas" when relocating a working CiviCRM install. (CiviCRM's wiki page on Moving an Existing Installation to a New Server or Location is seven pages printed out!) Here's what we watch out for when moving sites.
Filesystem paths
CiviCRM stores filesystem paths in various locations in the DB, which can cause a restored DB to not function when loaded in another location.
The simplest way to work around this is to use the facility to Override CiviCRM settings in civicrm.settings.php to ensure that all the settings in $civicrm_setting['Directory Preferences'] are "locked" to values which work in the new environment.
global $civicrm_setting;
$civicrm_setting['Directory Preferences']['uploadDir'] = '/path/to/site/sites/default/files/civicrm/upload';
$civicrm_setting['Directory Preferences']['imageUploadDir'] = '/path/to/site/sites/default/files/civicrm/images';
$civicrm_setting['Directory Preferences']['customFileUploadDir'] = '/path/to/site/sites/default/files/civicrm/custom';
$civicrm_setting['Directory Preferences']['extensionsDir'] = '/path/to/site/sites/default/civicrm/extensions';
$civicrm_setting['Directory Preferences']['customTemplateDir'] = '/path/to/site/sites/default/civicrm/custom_tpl';
This prevents the settings being changed via the web interface at civicrm/admin/setting/path while the settings are overridden in the settings file.
Sometimes Drupal has a variable civicrm_class_loader set with a fixed path - it may help to remove this variable.
drush vdel civicrm_class_loader
I think that I've seen mention of the hardcoded paths issues being addressed in 4.7 cycle, which would be great news IMO.
Definer in DB dumps
This is the most common cause of trouble reloading CiviCRM DB dumps.
The cause is that MySQL's default dump behaviour is to include trigger creator information in the dump - which will upset MySQL if you load the dump on a server where the original MySQL user doesn't exist. This looks like this in a MySQL dump:
/*!50017 DEFINER=`civicrmuser`@`localhost` */
The solution is really simple: use the --skip-triggers option when making your MySQL export. MySQL will omit the user-specific information, and CiviCRM will sort the triggers out the next time it rebuilds its caches.
If you've already got a large DB dump and don't want to make/transfer a new one just to remove that information, you can also do it using sed:
sed -E 's/DEFINER=`[^`]+`@`[^`]+`/DEFINER=CURRENT_USER/g' dump.sql > new dump.sql
I'm not sure if there are plans to address this?
Permissions
CiviCRM runs (in UNIX space) as the webserver/php user, and you probably restored the codebase / site files as your system user. In order to permit CiviCRM to function, you likely need to either change the ownership of the CiviCRM-writeable files to the webserver user (eg chown -R www-data: /path/to/sites/default/files/civicrm) OR find some other way to ensure that permissions are managed to ensure your user and the webserver user will not conflict.
There's an existing question on this topic: CiviCRM does not have permission to write temp files which covers the merits of various approaches to dealing with CiviCRM's special requirements when it comes to filesystem perms.
The main cause of this issue is the use of a disk cache for templates_c. Moving cached HTML to DB (as per Drupal's cache_* tables) or to a permissionless store (Redis, memcache etc) would remove this friction, but I'm not sure if / where that is on the roadmap.
Other considerations
You may also -
ConfigIDS.ini from your new site. CiviCRM will regenerate this file.civicrm/admin/extensions)civicrm/admin/setting/updateConfigBackend to reset CiviCRM's caches and stored pathsThis is what I do:
fixup all configuration files with the following script:
#! /bin/sh
#
remotebaseurl=<remote url>
remotewebroot=/var/www
remotesqlhost=localhost
localbaseurl=<local url>
localwebroot=/Library/Webserver/Documents
localsqlhost=127.0.0.1
localsqldb=<sqldb>
localsqluser=<sqluser>
localsqlpassword=<sqlpassword>
# save a backup of configuration files
backup() {
cp $1 $1.backup
}
backup administrator/components/com_civicrm/civicrm.settings.php
backup administrator/components/com_civicrm/civicrm/civicrm.config.php
backup administrator/components/com_civicrm/civicrm/templates/CRM/common/civicrm.settings.php.tpl
backup components/com_civicrm/civicrm.settings.php
# tweak all configuration files
sed -e "s|$remotebaseurl|$localbaseurl|" -i ".bak" administrator/components/com_civicrm/civicrm.settings.php
sed -e "s|$remotebaseurl|$localbaseurl|" -i ".bak" components/com_civicrm/civicrm.settings.php
sed -e "s|$remotewebroot/|$localwebroot/|" -i ".bak" administrator/components/com_civicrm/civicrm/civicrm.config.php
sed -e "s|$remotewebroot/|$localwebroot/|" -i ".bak" administrator/components/com_civicrm/civicrm.settings.php
sed -e "s|$remotewebroot/|$localwebroot/|" -i ".bak" administrator/components/com_civicrm/civicrm/templates/CRM/common/civicrm.settings.php.tpl
sed -e "s|$remotewebroot/|$localwebroot/|" -i ".bak" components/com_civicrm/civicrm.settings.php
sed -e "s|$remotewebroot/|$localwebroot/|" -i ".bak" media/civicrm/ConfigAndLog/Config.IDS.ini
rm -r media/civicrm/templates_c/*
sed -e "s|mysql://.*\?|mysql://$localsqluser:$localsqlpassword@$localsqlhost/$localsqldb\?|g" -i ".bak" administrator/components/com_civicrm/civicrm.settings.php
sed -e "s|mysql://.*\?|mysql://$localsqluser:$localsqlpassword@$localsqlhost/$localsqldb\?|g" -i ".bak" components/com_civicrm/civicrm.settings.php
echo "DONE!"
Feel free to copy and modify!