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

Hi!

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 7.6.1.0 Build 1163)

  • Hello,

    In config.php, It saves default settings and db connections. When you override any settings via admin or do it manually, It should be stored in config_override.php

    Any changes via admin, technically should not overwrite config_override. It may be reason that you write array in some other pattern then standard one.

    Thanks & Regards,

    Team Urdhva Tech

    Web: http://www.urdhva-tech.com

  • Thanks for your answer, you are right that the definition pattern is different, and also, if an override is the same than the default then it is just dropped (which makes sense). After another tests round, I see that it is working as expected, my bad, I were thinking that it was not working correctly because I'd saw my db configs dropped from the config_override, but this was because they were the same than in the config.php...(facepalm)

    Well I will be able to force a config.php commited through Git, and a config_override.php file which will be custom for each environment.