CiviCRM Community Forums (archive)

I think there are still a number of configuration settings stored in config_backend that should be moved out (probably to the preferences table). Mailer settings, component selections, etc.

When moving to a new server or doing an upgrade that field is often cleared and reset, requiring a review and re-setting of the global settings.

In my experience, when moving a site to a new server I almost always have to set config_backend to null in order to force Civi to rebuild the key settings (directory and resources url) for the new location. My order of operation is to update civicrm.settings.php, set config_backend to null, reload the site, and update preferences settings. The change resources url option rarely works for me unless I've cleared that field in the db, because Civi can't always load that page unless the settings are correct. If I'm moving from one directory to another on the same server, or from a temporary url to the live domain, that may work, but not if more is going on (new server, etc.).

http://wiki.civicrm.org/confluence/display/CRMDOC32/Moving+an+Existing+Installation+to+a+New+Server+or+Location
Note the troubleshooting section at the bottom -- which is standard procedure for me.

This brings up a bigger issue though -- moving a site to a new server requires quite a bit of work, and I seemingly need to reset the same values in several locations:

* two locations for civicrm.settings.php need to be updated (in Joomla)
* civicrm/civicrm.config.php needs to be updated if the file system path changed
* update directory path and url
* global settings: resources urls and directories (I find the resources urls don't alway update after the update directory path and url; directories I understand would need to be updated as there's warrant in controlling those locations in non-default places)
* reset the navigation menu

Civi is structured to accommodate some unique setups, such as multi-site installations, or hosting the codebase and db in an area separate from the rest of the CMS. but for the majority of standard installations, all these separate configs make it difficult to track.

what I'd like to see is a single civicrm.settings.php file that handles all other references. we define the global variables there, and no place else. if there are alternate configurations, they should be handled there as well. for example, i don't think the resource urls should be stored in the db at all -- why not just reference the value defined in the settings file? we could expose that value for reference in the interface, but why do we need to actually store it in the db?

obviously i'm coming from the joomla perspective, which has a few extra pieces to worry about (the duplicate civicrm.settings.php file and the hard coded file location in civicrm.config.php). but I would think the drupal implementation could be improved as well, and since the civicrm.settings.php file is site-specific in a multi-site implementation, why can't we base everything on on that file?