Migrated from Symphony Issue 577 and Basecamp.
Sometimes I'd like my config.php file to be able to contain custom code that won't be overwritten when Administration::saveConfig is executed (it'll overwrite the whole file right?).
Usecase could be
- config-values you want to share with your collegues while
.gitignoreing config.php. Put them in config.share.php and include the file in your original config
- custom actions, i.e. depending on the hostname used
If you add your custom config in the same key/value pairs to config.php, do they still get overwritten?
Another option is to allow Symphony to auto-load config files config.*.php after the main configuration file, appending the additional values to the config array?
So there's two things here, wanting to be able to include other files that include values (so they can be accessed from the Configuration class), and then the desire to have arbitrary PHP code.
Nick's idea for config.*.php would solve the first, with the caveat that these files could not be modified by Symphony (although this doesn't seem like an issue with the scenario you've used), instead they would be appended to the main config.php, which probably isn't desirable.
As for the second, well I guess if we are loading config.*.php in a readonly state, then your custom code could live in here. It wouldn't be available in Symphony, but only the $settings variable is added to the Configuration class.
custom actions, i.e. depending on the hostname used
Interested point. We could create a file named environments.php in the manifest folder that contains specific config for each hostname used.
Ok, so I’m back to developing a site in Symphony and Git and I’ve come across a stumbling block already.
I’ve grown accustomed to using a switch statement in PHP to store different database details dependant on which server the site is being run on.
With this in mind, I thought I’d start being clever about how my prefs were being stored in the Git repo, i.e. storing the entire config.php file so that the same preferences were being used across the development. The plan was to leave the default database settings in there (with no db name, username or password), and include a database.php file at the bottom, which would house the database connection details, inside this switch statement. This file would not be stored under the Git repo.
It works! Well, until someone changes the preferences that is, then the include is deleted from the file. Hmmm, damn.
I would have thought that the writing of configuration details would work like the .htaccess writing, whereby it reads the file, drops in/pulls out the respective bits as required, then writes the whole file back. It seems that it isn’t doing this.
Can we change this so that my use case can be a working solution? Would it be difficult to do?
There are two solutions currently being thought about:
- Introduce a marker in the file that prevents Symphony from overwriting everything that follows it. I.e.
$settings = array(
###### ADMIN ######
'admin' => array(
'max_upload_size' => '5242880',
),
########
...
);
###### SYMPHONY_END ######
// I can add whatever I want. Yay!
$settings['database'] = array(...);
- Make Symphony load several config files automatically, following a certain naming convention. I.e.
config.php first, then *.config.php, sorted alphabetically.
The first approach follows the “code by configuration”-concept, the second one the “code by convention”-concept (like most of the rest of Symphony). Both solutions would be backwards-compatible but would fail in different situations: The first one will simply be ignored and overwritten (your changes are gone once you hit “Save” in the preferences pane). The second one would not be overwritten but all extra-files would simply have no effect.
Can we change this so that my use case can be a working solution? Would it be difficult to do?
It wouldn’t be difficult to do such thing. I’ve been discussing this functionality with Brendan here, and this feature will come in the next version of Symphony (2.2.2).
Instead of using markers in config.php I think a simple read-only file called environments.php can solve this problem. Actually the second situation Nils mentioned would not fail because extra configuration files will be useful for distributing extension configurations, and they have to be considered as normal configuration files like config.php.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent
