{"issue":{"state":"open","pull_request":{"diff_url":null,"html_url":null,"patch_url":null},"milestone":{"state":"open","open_issues":9,"url":"https://api.github.com/repos/symphonycms/symphony-2/milestones/3","due_on":null,"title":"2.x","description":"Encapsulates all future releases on the 2.x branch.\r\n\r\nIssues assigned to this milestone are on the roadmap, but have not been decided when they'll make into a specific release.","creator":{"avatar_url":"https://secure.gravatar.com/avatar/6be8e584a0f454ac2dc7600bdeaca7b7?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"6be8e584a0f454ac2dc7600bdeaca7b7","url":"https://api.github.com/users/brendo","login":"brendo","id":69268},"number":3,"closed_issues":1,"created_at":"2011-07-03T03:24:13Z"},"user":{"avatar_url":"https://secure.gravatar.com/avatar/6be8e584a0f454ac2dc7600bdeaca7b7?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"6be8e584a0f454ac2dc7600bdeaca7b7","url":"https://api.github.com/users/brendo","login":"brendo","id":69268},"assignee":null,"updated_at":"2011-11-15T14:18:24Z","labels":[{"name":"to discuss","color":"d87ef1","url":"https://api.github.com/repos/symphonycms/symphony-2/labels/to+discuss"}],"closed_at":null,"comments":7,"url":"https://api.github.com/repos/symphonycms/symphony-2/issues/669","body":"Migrated from [Symphony Issue 577](http://symphony-cms.com/discuss/issues/view/577/) and Basecamp.\r\n\r\n#### @nils-werner\r\n\r\nSometimes 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?).\r\n\r\nUsecase could be\r\n\r\n* config-values you want to share with your collegues while `.gitignore`ing `config.php`. Put them in `config.share.php` and include the file in your original config\r\n* custom actions, i.e. depending on the hostname used\r\n\r\n#### @nickdunn \r\nIf you add your custom config in the same key/value pairs to `config.php`, do they still get overwritten?\r\n\r\nAnother 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?\r\n\r\n##### @brendo\r\nSo 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.\r\n\r\nNick'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.\r\n\r\nAs 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.\r\n\r\n#### @rainerborene\r\n\r\n> custom actions, i.e. depending on the hostname used\r\n\r\nInterested point. We could create a file named `environments.php` in the manifest folder that contains specific config for each hostname used.\r\n\r\n#### @designermonkey\r\n\r\nOk, so I’m back to developing a site in Symphony and Git and I’ve come across a stumbling block already.\r\n\r\nI’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.\r\n\r\nWith 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.\r\n\r\nIt works! Well, until someone changes the preferences that is, then the include is deleted from the file. Hmmm, damn.\r\n\r\nI 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.\r\n\r\nCan we change this so that my use case can be a working solution? Would it be difficult to do?\r\n\r\n#### @nils-werner\r\n\r\nThere are two solutions currently being thought about:\r\n1. Introduce a marker in the file that prevents Symphony from overwriting everything that follows it. I.e.\r\n\r\n\t\t$settings = array(\r\n\t\t###### ADMIN ######\r\n\t\t   'admin' => array(\r\n\t\t       'max_upload_size' => '5242880',\r\n\t\t   ),\r\n\t\t   ########\r\n\t\t   ...\r\n\t\t);\r\n\t\t###### SYMPHONY_END ######\r\n\t\t// I can add whatever I want. Yay!\r\n\t\t$settings['database'] = array(...);\r\n\r\n2. Make Symphony load several config files automatically, following a certain naming convention. I.e. `config.php` first, then `*.config.php`, sorted alphabetically.\r\n\r\nThe 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.\r\n\r\n#### @rainerborene\r\n\r\n> Can we change this so that my use case can be a working solution? Would it be difficult to do?\r\n\r\nIt 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).\r\n\r\nInstead 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`.\r\n\r\n\r\n\r\n\r\n","html_url":"https://github.com/symphonycms/symphony-2/issues/669","title":"\"Ignore everything after this\" marker in `config.php`","number":669,"id":1066282,"created_at":"2011-06-16T09:08:46Z"},"action":"created","comment":{"user":{"avatar_url":"https://secure.gravatar.com/avatar/8f954979f1235a6d320a0659472b76f6?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"8f954979f1235a6d320a0659472b76f6","url":"https://api.github.com/users/remie","login":"remie","id":435237},"updated_at":"2011-11-15T14:18:24Z","url":"https://api.github.com/repos/symphonycms/symphony-2/issues/comments/2745093","body":"I'd be happy to pick it up... but it depends on the due date: when is the 2.3 release scheduled? November / December is a bit busy for me.","id":2745093,"created_at":"2011-11-15T14:18:24Z"}}