AnsweredAssumed Answered

Best practices regarding usage of config_override.php vs config.php

Question asked by Jeff Girard on Dec 29, 2015
Latest reply on Jan 4, 2016 by Jeff Girard



I'm trying to figure out how we should work with config.php vs config_override.php. My understanding was that I should let config.php part of the codebase, and add to gitignore the config_override.php.


This way, I was assuming that:

- the config.php would contain everything we want to propagate to every environments (dev, staging, production, many developer workstations...)

- and the config_override.php would contain environment-specific configuration, like "dbconfig" values, etc.


...But it looks like I was wrong! :/


The problem: I was aware that when we change some settings in "Administration" from the web interface, that backend it directly changes the config_override.php... but I'm surprised that it completely wipe out my override when I'm just changing a single value from the administration page like for example the address of my elasticache server... I'm losing everything I manually typed in config_override.php.


My file was containing a bunch of stuff already defined from the Administration page, everything was contained in a "/**** CONFIGURATOR ****/" block, and after this block I've added my custom configuration for my database. But once I go back into Administration page, change a setting and save, boom, config_override.php is getting overwritten!


My question: What is the correct usage I should follow regarding config.php vs config_override.php?  SugarCRM documentation isn't very clear regarding this, and especially regarding the fact that changing settings through the administration page can flush our existing manually-inserted configurations from the config_override.php...


Thanks for any help!


(SugarCRM Enterprise Build 1163)