Answers.Body: <p>There are multiple "gotchas" when relocating a working CiviCRM install. (CiviCRM's wiki page on <a href="http://wiki.civicrm.org/confluence/display/CRMDOC/Moving+an+Existing+Installation+to+a+New+Server+or+Location" rel="nofollow noreferrer">Moving an Existing Installation to a New Server or Location</a> is seven pages printed out!) Here's what we watch out for when moving sites.</p>
  
  <p><strong>Filesystem paths</strong></p>
  
  <p>CiviCRM stores filesystem paths in various locations in the DB, which can cause a restored DB to not function when loaded in another location.</p>
  
  <p>The simplest way to work around this is to use the facility to <a href="http://wiki.civicrm.org/confluence/display/CRMDOC/Override+CiviCRM+Settings" rel="nofollow noreferrer">Override CiviCRM settings in <code>civicrm.settings.php</code></a> to ensure that all the settings in <code>$civicrm_setting['Directory Preferences']</code> are "locked" to values which work in the new environment.</p>
  
  <pre><code>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';
  </code></pre>
  
  <p>This prevents the settings being changed via the web interface at <code>civicrm/admin/setting/path</code> while the settings are overridden in the settings file.</p>
  
  <p>Sometimes Drupal has a variable <code>civicrm_class_loader</code> set with a fixed path - it may help to remove this variable.</p>
  
  <pre><code>drush vdel civicrm_class_loader
  </code></pre>
  
  <p>I think that I've seen mention of the hardcoded paths issues being addressed in 4.7 cycle, which would be great news IMO.</p>
  
  <p><strong>Definer in DB dumps</strong></p>
  
  <p>This is the most common cause of trouble reloading CiviCRM DB dumps.</p>
  
  <p>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:</p>
  
  <pre><code>/*!50017 DEFINER=`civicrmuser`@`localhost` */
  </code></pre>
  
  <p>The solution is <em>really</em> simple: use the <code>--skip-triggers</code> 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.</p>
  
  <p>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 <code>sed</code>:</p>
  
  <pre><code>sed -E 's/DEFINER=`[^`]+`@`[^`]+`/DEFINER=CURRENT_USER/g' dump.sql &gt; new dump.sql
  </code></pre>
  
  <p>I'm not sure if there are plans to address this?</p>
  
  <p><strong>Permissions</strong></p>
  
  <p>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 <code>chown -R www-data: /path/to/sites/default/files/civicrm</code>) OR find some other way to ensure that permissions are managed to ensure your user and the webserver user will not conflict.</p>
  
  <p>There's an existing question on this topic: <a href="https://civicrm.stackexchange.com/questions/2923/civicrm-does-not-have-permission-to-write-temp-files/2931#2931">CiviCRM does not have permission to write temp files</a> which covers the merits of various approaches to dealing with CiviCRM's special requirements when it comes to filesystem perms.</p>
  
  <p>The main cause of this issue is the use of a disk cache for <code>templates_c</code>. Moving cached HTML to DB (as per Drupal's <code>cache_*</code> 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.</p>
  
  <p><strong>Other considerations</strong></p>
  
  <p>You may also -</p>
  
  <ul>
  <li>need to remove the file <code>ConfigIDS.ini</code> from your new site. CiviCRM will regenerate this file.</li>
  <li>need to trigger CiviCRM to revisit its idea of which extensions are installed ("Refresh" @ <code>civicrm/admin/extensions</code>)</li>
  <li>need to visit <code>civicrm/admin/setting/updateConfigBackend</code> to reset CiviCRM's caches and stored paths</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-15T16:06:39.137Z
Answers.LastActivityDate: 2015-09-15T18:37:31.547Z
Answers.LastEditDate: 2017-04-13T12:53:13.017Z
Answers.UserDisplayName: Chris Burgess
Answers.Body: <p>This is what I do:</p>
  
  <ul>
  <li>take a backup (I use Akeeba, since I'm almost always Joomla-based)</li>
  <li>restore it on the new server (Akeeba kickstart, to your aid)</li>
  <li><p>fixup all configuration files with the following script:</p>
  
  <pre><code>#! /bin/sh                                                                                                                                                               
  #                                                                                                                                                                        
  remotebaseurl=&lt;remote url&gt;
  remotewebroot=/var/www
  remotesqlhost=localhost
  localbaseurl=&lt;local url&gt;
  localwebroot=/Library/Webserver/Documents
  localsqlhost=127.0.0.1
  localsqldb=&lt;sqldb&gt;
  localsqluser=&lt;sqluser&gt;
  localsqlpassword=&lt;sqlpassword&gt;
  
  # 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!"
  </code></pre></li>
  </ul>
  
  <p>Feel free to copy and modify!</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-15T15:38:06.597Z
Answers.LastActivityDate: 2015-09-15T15:38:06.597Z
Answers.UserDisplayName: thoni56
Body: <p>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.</p>
  
  <p>Is there a way that always works?</p>
  
Tags: <backups><webserver>
Title: How do I get a backup of CiviCRM working on a different server?
ThreadText: # How do I get a backup of CiviCRM working on a different server?
  
  (Asked by: username_0 on 2015-09-15)
  
  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?
  
  **Tags:** backups, webserver
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2015-09-15. Score: 4
  
  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
  
  
  ---
  
  ### Answer by username_0 on 2015-09-15. Score: 1
  
  This is what I do:
  
  take a backup (I use Akeeba, since I'm almost always Joomla-based)
  restore it on the new server (Akeeba kickstart, to your aid)
  fixup all configuration files with the following script:
  #! /bin/sh                                                                                                                                                               
  #                                                                                                                                                                        
  remotebaseurl=
  remotewebroot=/var/www
  remotesqlhost=localhost
  localbaseurl=
  localwebroot=/Library/Webserver/Documents
  localsqlhost=127.0.0.1
  localsqldb=
  localsqluser=
  localsqlpassword=
  
  # 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!
  
  
  ---
  
  