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 -
- need to remove the file
ConfigIDS.ini
from your new site. CiviCRM will regenerate this file.
- need to trigger CiviCRM to revisit its idea of which extensions are installed ("Refresh" @
civicrm/admin/extensions
)
- need to visit
civicrm/admin/setting/updateConfigBackend
to reset CiviCRM's caches and stored paths