Suitecrm: Directory to store configs instead of having a huge config_override.php

[Abuelodelanada]

Issue

In large instances of SuiteCRM it is very common to use the config_override.php file to store:

• Application configs like:

$sugar_config['dbconfigoption']['collation'] = 'utf8_general_ci';
$sugar_config['default_time_format'] = 'H:i';
$sugar_config['default_date_format'] = 'd/m/Y';
$sugar_config['datef'] = 'd/m/Y';

• Performance configs like:

$sugar_config['disable_count_query'] = true;
$sugar_config['verify_client_ip'] = false;
$sugar_config['stack_trace_errors'] = false;
$sugar_config['use_real_names'] = false;

• And business configs like:

$sugar_config['roles_filial'] = array(
    'Planta' => 'OperadorPlanta',
    'AC' => 'OperadorActivador',
    'ONP' => 'OperadorONP',
    'ASR' => 'OperadorAsesor',
    'GTE' => 'SupervisorPlanta',
    'GC' => 'SupervisorGC',
    'GC' => 'OperadorGC'
);

• Etc

When doing this, the config_override.php file became huge, and it is no easy to mantain. With this you can easily have a +2500 lines in config_override.php.

Expected Behavior

Have a more neat way of storing configurations.

Actual Behavior

We have only one file to store configurations that overrides (and extend) the ones that are in config.php

Possible Fix

May be we can have a configs/ directory where we can store small config files.
After loading config_override.php SuiteCRM should scan configs/ directory and require that files.

In this way it is easy to mantain configurations.

[isleshocky77]

This should probably be part of a larger restructuring issue. I tend to like how Symfony has been doing it copying the linux structure of having

• /etc
• /var/logs
• /var/cache
• /bin

It looks like with the new API a lot of stuff was already move to /lib which is good with me.

I've started trying to move the logs and cache out of the root and had some issues with cache that I'll try to reproduce and ticket if I have a chance. (It's around javascript cache generation not respecting the config var.

[frnklnrd]

I really like this idea. Even, I can propose something more.
I have made some code personalizations to include an extra file according to the "environment" (local, development, testing, production, etc.)
I propose consider a configuration variable that indicates the environment, not only "developmentMode = true", and similar to Symfony, configurations files can be loaded according to the environment.