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](http://wiki.civicrm.org/confluence/display/CRMDOC/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`](http://wiki.civicrm.org/confluence/display/CRMDOC/Override+CiviCRM+Settings) 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](https://civicrm.stackexchange.com/questions/2923/civicrm-does-not-have-permission-to-write-temp-files/2931#2931) 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=<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!
  
  
  ---
  
  