"Ignore everything after this" marker in `config.php` about symphonycms

[designermonkey]

I see that this has been pushed back to 2.3, which is better than 2.2.2 IMO as it gives us more time to discuss the best solution for this, although I would like this to be included in 2.2.3. I've been having a think about what would be awesome, and that would be to mimic Ruby's environments somehow, but this is out of scope for 2.x and better discussed for 3.

I reckon that Nils' first solution would be the best to implement and the easiest transition for the 2.x version, for current users. The other solution offered is too much of a change for people to deal with IMO, we need to keep the change simple to comprehend.

PS, the only reason I'm bringing this up now is my urgent need to do this on projects, I'm having to run separate setups for deployments... ;o)

[nickdunn]

As John says, I think this conversation should be expanded to also include discussion about storing per-environment stuff in config. This has been partially addressed in the Symlink Manifest extension, but it'd be nice for this to be considered in Symphony core.

[brendo]

I love the idea of environment based configs. At work we use Rowan's technique by symlinking a dev and live manifest and it's incredibly useful and timesaving after the initial setup. I actually didn't realise someone had created an extension to do something similar, I'll have to check out!

[designermonkey]

I really like Rowan's workaround for multiple setups, and I've tried to use it on a recent project, however it, and the extension, aren't greatly intuitive and means duplicating unnecessary parts of the config file. The onlt real duplication needed are the DB settings IMO, as the environments shouldn't change really other than that...

[nickdunn]

Related: New way to do preferences, lots of good stuff.

[brendo]

Descoped for 2.3, perhaps in a point release. @kirkstrobeck did have some nice ideas in that thread, and I do like the prospect of Rails style environment configuration.

This issue needs an owner though, if that sounds like you by all means, take this and run with it. There is a couple of ideas floating around but we really need to single one out and go for it. Ideally the idea will:

• require minimal core changes
• require no breaking changes to the Configuration class
• be relatively backwards compatible with the ability to update the old format to the new format
• be secure
• implement the minimum, and allow an extension to take care of the edge cases

/cc @czheng @remie

[remie]

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.

[designermonkey]

@remie this won't be doable by 2.3 so don't rush if you want to do it. This needs to be done well (which I know you will do), and should have some time dedicated to it.

[remie]

In that case: I'd be happy to be assigned to this issue.

[brendo]

What @designermonkey said, when working out your concept/approach just keep in mind the bullet points above :)

Thanks @remie!

[remie]

I've created a design document for this issue

I'd love to hear your thoughts about his @brendo, @rainerborene, @designermonkey @nickdunn and @nils-werner. Please don't forget to mention which implementation you prefer!

[brendo]

Thanks for this @remie. My preference is Environment specific configuration files (included on naming convention). I think it's the quickest concept to pick up.

That said, this solves the problem of configs between environments. There may be a situation where truly custom code is needed in which case a hybrid between having specific environment configuration files (3) and having private sections within these files (1) would be ideal.

Regardless, we can always do (3) first and then assess later if the functionality that (1) provides is actually needed.

[nickdunn]

My preference is Environment specific configuration files (included on naming convention)

Ditto.

As an aside, I had implemented locally some time ago and it worked for reading config, but the minute I came to save I had problems deciding where to persist each key, since everything is loaded into the global config array in memory without any marker of where the config value came from. I presume the read works in one direction:

1. Load config.php array
2. Look for environment file
3. Read array, unset existing values from loaded config, replace with these

And the write would be in the reverse:

1. Look for environment file
2. Pluck any values required in this file from the loaded config
3. Unset these
4. Persist the rest to config.php normally

[brendo]

Yeah it's interesting, I almost see that a file has to keep track of whether to load production or development itself and then all values will be persisted in full in config.{env}.phpfiles. So we might have aconfig.phpfile that just has a single setting,env_mode, which then tellsConfigurationclass to loadconfig.{env_mode}.php. Thisenv_modeis remembered byConfiguration` for all subsequent reads/writes.

The con is that you wouldn't be able to access the settings in other environments, why you'd want to do this I'm not sure, and it wouldn't be impossible to get around, but still worth saying at this stage.

[nickdunn]

Hmm. I think each value (well, key) in the config needs to now its origin. An extension might want to persist its config values to the environment specific config instead of the global config. This could be an extra argument to the set() method? So every key might have an internal _origin or _provenance or _global: yes/no flag so it knows where to be persisted to.

[brendo]

Hm, that is a different approach.

I thought that the 'global' config.php would cease to exist, so everything would be duplicated across config.{env_mode}.php files instead of having one master file and then overriding the particular values from the environmental configs.

I worry that introducing those sorts of properties makes the config file harder to read and process for extensions. The Configuration class IMO should return the configuration properties that are active for the current environment.

I can see cases boths ways though :)

[nickdunn]

I thought that defeats the object of the piece, duplicating everything. I thought there'd be a global config, and then per-environment overrides for things that change in each environment (i.e. database).

[remie]

I thought that defeats the object of the piece, duplicating everything. I thought there'd be a global config, and then per-environment overrides for things that change in each environment (i.e. database).

I go with Nick here: there should be a main configuration file (config.php) in which all settings are declared with default values. Environment specific settings are normally just a small subset that needs to be adjusted (like the database username / password). The environment specific configuration files should override the default configuration.

My only concern with option 3 (Environment specific configuration files) is that it introduces the possibility of human error. What if you only update your local environment config file, and not the global config file? To ensure that the default value is present in the global config.php, the override should only be possible if the setting already exists. No new settings should be allowed in the environment specific configuration.

[brendo]

Fair point.

So do we have to explicitly declare that 'x' overrides 'y'? Or do we just use a priority tree, so values in one environment have a higher priority than those in another?

How are we going to do the environments? Do we hardcode in development, acceptance and production values? Or are these user defined? If they are user defined, do we just have a special line at the top that states that this overrides: x, y, z environments?

[designermonkey]

We (IMO) need a default config file that has all values in it, and then separate ones for environments, as discussed above.

I don't think we should have a hierarchy at all, we should be specifying somewhere that the environment has changed, via a parameter.

Where this is, Is beyond me. In Codeigniter, it is in the base index.php file as it is loaded first, but that doesn't work for me in Symphony's context.

[nickdunn]

• config.php (global)
• config.mysite.local.php (used when hosted on http://mysite.local)
• config.mysite.dev.mydomain.com (used when hosted at http://mysite.dev.mydomain.com)
• config.mysite.com (used when hosted at http://mysite.com)

The per-config files would just contain any overrides to the global config. They are optional files (convention over configuration). Small problem here is if you use domain aliases, multiple hostnames.

An alternative is two files config.php (global) and config.env.php. The former goes in source control, the latter does not. config.env.php overrides the global.

Sorry, straying away from Remie's design doc here.

[nickdunn]

Or, as I've said somewhere else (can't remember where, forum?) maybe each key in the config could be saved to its own file. So if database is flagged as such, it is saved to config.database.php instead of being persisted to the global config.php.

[nils-werner]

So do we have to explicitly declare that 'x' overrides 'y'?

I'd say let PHP do the work. Re-declaring variables (or merging Arrays) should suffice as our overloading-mechanism.

Small problem here is if you use domain aliases, multiple hostnames.

Also if two people use the same .local hostname but different settings.

So if database is flagged as such, it is saved to config.database.php instead of being persisted to the global config.php.

That'd make things cleaner but doesn't solve the issue, does it?

Maybe each config file could have a pointer to the next one, effectively making them chaineable. You could then have as many environments as you like and track the important ones using Git but gitignore the middleman (the one that decides what environment to pick on each individual machine).

As to the saving: Still save everything to the default config.php. The values that are being overloaded may start switching values depending on who saved the file last but that doesn't matter to the others, it's their responsibility to overload them reliably.

But I think we're overcomplicating things a bit...

[remie]

But I think we're overcomplicating things a bit...

Indeed we are :)
My suggestion would be to keep it simple and use the alternative mentioned by Nick: have a global config.php which goes into version control and only include config.env.php (based on naming convention) to allow environment specific overrides. The latter does not go into version control.

It will be the responsibility for each developer to put the correct environment specific values in it for their local environment, and the responsibility for the release manager to do so for T/A/P environments.

This way Symphony can still write to the global config.php file, it ensures there is default configuration available and it provides the required flexibility. Is there really a use-case for making the config files chainable?

[nils-werner]

Is there really a use-case for making the config files chainable?

Unfortunately, yes. If you gitignored all environment-specific configs you couldn't change a setting on a remote server (staging or production etc.) using Git but you would have to manually edit the file there.

Not really a usecase for "chaining" but for "committing but ignoring some environments".

[remie]

you would have to manually edit the file there.

In all non-scripting development languages this is a best practice. Usually, the only information you would place in there would be environment specific credentials, right? This should not live in version control anyways. However, I do realize that this does not work with the FTP deployment common to scripting languages like PHP. So you're right, it is a valid use case, even if it is a bad practice.

So the only way to solve this is by using a naming convention based on hostnames. This works for T/A/P environments. If the local development config files aren't placed under version control, you will not have a problem with domain aliases, multiple hostnames or the same *.local hostname.

[nils-werner]

you would have to manually edit the file there.

In all non-scripting development languages this is a best practice.

Oh? I would've assumed otherwise. What do the others think about it?

On second thought Nicks config.<hostname>.php idea is actually quite elegant. If you combine it with the "only save to global config.php, dont touch env-configs" pragma the multiple hostnames problem could be solved easily too. The only issue would be multiple people using local installs on the same hostname.

[remie]

The only issue would be multiple people using local installs on the same hostname.

You can solve this by telling them that the local environment configuration file should not be put into version control. So only add T/A/P specific configuration in GIT. That would work.

[nils-werner]

Hah, obviously.

[henrysingleton]

Another vote for the config.<hostname>.php approach. I'm using Rowan's symlink manifest.live / manifest.dev approach, and while it works well, using extensions like the Global Resource Loader make things a pita if I forget to add new DSs and events to manifest.live and vice-versa.

The approach is nice and elegant, and nobody even has to know it's there if they don't want to use it. Also, having only one config file by default makes it a lot easier for newbies to know where to look to change stuff.

[brendo]

The hostname idea is pretty elegant, I like it!

[remie]

So we have a winner! Thanks @nickdunn
I will start with implementing it. As soon as I have a working branch I will update this thread.

[nils-werner]

Because some extensions rely on installation-independent config settings (dump_db saves when it has been used last) we also need to discuss a way to determine where certain config settings will be saved.

Nick suggested an algorithm that detected array keys that have been overridden in an environment-config, I am a bit concerned though that it would become complicated or buggy in weird config-scenarios.

Alternatively, I can imagine another optional parameter for one of the Configuration:: methods, one that lets the developer decide if the value should go in the global or in the local config, if available.

[remie]

one that lets the developer decide if the value should go in the global or in the local config, if available.

The Configuration class should never write to the local config.
Because we now have the ability to keep the environment specific changes in GIT, you can always override this setting for a specific environment if required.

So global.php is leading. This is where the action's at. It is the responsibility of the developer to review config changes and add environment specific overrides where applicable.

[nils-werner]

But some extensions modify the config quite often and rely on it being up to date. If I overrode those values once in a static environment specific config, I'd lose the ability to use that feature.

Conversely, if I didn't overrode the setting my local installation of that extension would get confused by settings saved by others.

I think there is a need for Configuration to be able to save to environment specific configs in those (probably quite rare) instances.

[brendo]

If an extension wrote data to config.php and the values were not overridden by a developer in config.domain.php, then the Configuration class would return the value of the parameter as it stands in config.php. If however the developer added the same group to the config.domain.php, then these values would 'override' the values (read-only) in config.php and be returned by the Configuration class.

Is that what we are shooting for?

But some extensions modify the config quite often and rely on it being up to date. If I overrode those values once in a static environment specific config, I'd lose the ability to use that feature.

Isn't that the catch of having overrides? That you are responsible for the values that are going to override the default values? If an extension was able to overwrite your local config, that could be dangerous considering it wouldn't be kept in version control right?

While extending the Configuration class to allow it to write to both config.php and config.domain.php is trivial, it could be potentially dangerous and piss off people who overrode things for a reason. Given there is no specific use case for that functionality, I think we can ignore it until that time comes (if it comes).

I think the most common use case for this environment functionality is database credentials right?

[nickdunn]

Is that what we are shooting for?

That is my understanding.

I think the most common use case for this environment functionality is database credentials right?

Three common cases for me:

• database details
• email (local using sendmail, live using SMTP)
• Remie's Github oAuth extension (different application keys for different URLs). In this instance I'd want changed to be stored into the local/domain config, I think

[nils-werner]

Is that what we are shooting for?

I think so, yes.

I think the most common use case for this environment functionality is database credentials right?

Another one for me: dump_db saves a timestamp of when there has been the last transaction (dumping DB into a file or a re-import of that file). It then compares the modified-date of those files to the timestamp in the config and notifies the administrator if one of the .sql files is newer than the last action, asking him to do a re-import.

This works fine as long as all installation-configs are kept separate; each installation keeps track of its last dump-actions. If we disallowed writing to environment-specific configs, that timestamp would end up in the common settings, breaking that feature.

This could be prevented if the extension purposefully wrote to the environment-specific config (if that file exists): Each installation has read/write-access to it's own dump_db-timestamp again.

[remie]

Another one for me: dump_db saves a timestamp of when there has been the last transaction

I have two considerations with this:

1. Perhaps dump_db should not write this information to the configuration file?
2. I would believe this information to be environment specific (or database schema specific)? Changes made to the database on my development environment are not in line with those on production / local environments of other developers.

For me, having Configuration class writing to the environment specific configuration files would defeat the purpose of this feature.

[nickdunn]

For me, having Configuration class writing to the environment specific configuration files would defeat the purpose of this feature.

But how then do we achieve environment-specific config that is editable through the UI? Such as the Github oAuth extension, which exposes these variables through the System Preferences page. They should be different per environment (different domains and keys).

[nils-werner]

For me, having Configuration class writing to the environment specific configuration files would defeat the purpose of this feature.

Not if the data being saved is also environment-specific.

Such as the Github oAuth extension, which exposes these variables through the System Preferences page.

Exactly, extensions that have inputs on the Preferences page will wildly edit the global config and write whatever people have in their environment-specific config. Same goes for the email gateway settings, right?

But how then do we achieve environment-specific config that is editable through the UI?

Two solutions come to my mind:

1. As previously suggested, add a parameter "write to environment-specific config" to one of the Configuration methods. Requires those extensions to be updated.
2. Add a key to the config (overrulable obviously) that contains all keys that must be written to environment-specific config. Works with all current extensions.

[remie]

Not if the data being saved is also environment-specific.

The whole point of environment specific configuration is that you want to have control over what the value is for that specific environment. You want it to be a manual task to update the configuration, because you want to be sure that this is the value that is used in that specific environment.

I would really only entertain two options:

1. We disable the option to edit configuration settings though the UI for all options on the preference screen that have environment specific values.
2. Add a seperate screen where you allow editing of environment specific configuration files (showing only those values that have been overridden).

[designermonkey]

This is getting very complicated and confusing.

The simple approach would be that if a key has been set in the environment specific config, then the Configuration class should therefore write that key to the specific file, not the default file.

Sounds simple to me...

[remie]

This is getting very complicated and confusing.

You're right. perhaps we need a break.
Perhaps we need to sum up all the different views on how to deal with configuration files and pick it up from there?

[nils-werner]

The whole point of environment specific configuration is that you want to have control over what the value is for that specific environment.

I agree.

You want it to be a manual task to update the configuration, because you want to be sure that this is the value that is used in that specific environment.

Some extensions or features prohibit that, they're changing the file without letting the user know.

1. We disable the option to edit configuration settings though the UI for all options on the preference screen that have environment specific values.

That probably won't be possible I am afraid. The preferences page alone is littered with stuff that's trying to write to that file. It would be really hard to make sure everything still works.

2. Add a seperate screen where you allow editing of environment specific configuration files (showing only those values that have been overridden).

That could work but it doesn't solve the case when extensions are writing to config without showing it to the user.

[designermonkey]

From my perspective (as one of the original people who asked about this), we need to do the following to start the process:

1. Make the Configuration class write values by single key only, not the whole batch or nothing approach that is currently in place.
2. Give the Configuration class the ability to write to different files via a defaulted parameter, just in case we want to pursue that road in the future.

Reasons:

1. Extensions pass along single sets of values to write, yet the class pulls the entire configuration file, edits the specific set, then writes the entire file. This seems a little overkill to me.

Also to note, I don't like the fact the config is a PHP array that gets parsed all the time, it needs to be XML for the future IMO.

[designermonkey]

Are we scoping this for 2.4

[brendo]

If there's enough momentum, sure. After the issue tracker is cleared out during hackathon we'll be able to clearly see the remaining 'new feature' issues and quickly plot them in terms of difficulty, reward and resources. This will help us plan future releases better.

[remie]

Perhaps we can break up this issue into multiple tasks and start with implementing an XML based config file. Although it might perform less than an PHP array, because we'll need to parse the file, it is more in line with other design decision like looking into moving section definition from database to XML.

We can move forward from there, for instance by adding a <import file="" /> tag which allows everyone to add custom imports to the configuration.

[designermonkey]

When 2.3 is released, and the integration branch becomes 2.3.x, I'd like to see this pulled in for testing. It's a great step in the right direction.

[brendo]

Definitely, I'm really happy with @remie's initial effort as it looks to be a non breaking change. Extensions (and the core) that access the Configuration through the appropriate methods won't notice the difference if it's stored as PHP or XML.

I'll be testing once Beta 3 is out :)

[designermonkey]

I've been doing some tinkering with an idea round this config thing, to try and take into account all ideas here while keeping it simple. I've tried to keep all the config options within one file, including environment specific options, and extension options too.

The result is this.

I took the liberty of moving some of the config options to make the file more meaningful and concise. This in whole is a move to try and follow the work that was done for the extension meta files. The problem is that we would have to do some work on the Symphony Preferences page to accomodate this style of config. Let me explain my ideas...

1. Environments

The environments node is where we would put info about our extended configuration options in the form of a handle which we would use to reference the environment, a meaningful name to be used in Symphony and a url to match the site root against (which would instigate the override).

We then use the handle as a reference to which settings groups should be parsed by the Configuration class.

2. Settings Groups

Each configuration group has a child node of settings which carries an env attribute where we can specify the environment which the options should be loaded. My intention is that only options which you want to change need specifying in another group other than default. Because of this, I'm of the thinking that we will need to parse the default options, then dependent on the environment, load any environment specific options to override the default.

I'm all for this idea as it allows us to use xPath to pick up any overrides, without having to crawl the entire file with if/else logic.

There needs to be more specific discussion around this as it may become memory intensive, however I see it as quicker and easier than the PHP that we currently have.

3. Extensions

Each extension is identified by the ID that must be provided in the extension meta file. Keeping them in the same format as the other options in the config allows us to specify options on a per environment basis too, which is a bonus.

Now, I'm still open to discussion around whether extension config options need to be separated into another file, or left as they are in my example.

4. Preferences UI

This is the biggest part of the idea, and could be the sticking point if we can't agree on how we approach this. I have an idea to completely overhaul the preferences area of the Symphony admin. I do believe that this is the most neglected part of Symphony, and it's time we did something with it as part of this project.

To allow us to use the idea I'm proposing, we need to think about how we display the multiple environments to the user. In the vision I had with this idea, we offer the user tabs for each meaningful name provided, per config group in the xml. I also really think we should be offering a UI for every option group in the config file which we currently don't do.

So, for each option group (log, database, symphony, public etc) we offer a fieldset, and within that fieldset we have a tab for each environment, whether there have been options set for that environment in the config file or not. Any options not set are just empty. All the options under 'Default' need to be filled in for the form to submit.

As there are some extensions that don't store options in the config file but need to be configured, we need to provide a separate section on the preferences page for these cases (think JIT).

---

This is quite a change from our current approach, and is definitely going to take some doing to implement, but as we've shown with extensions, the benefits can be greater than we first think. If anyone wants me to explain this more, please ask. I really could do with getting some UI mockups done, but I'm crap with design stuff.

[nickdunn]

I was nodding enthusiastically until

I also really think we should be offering a UI for every option group in the config file which we currently don't do.

I disagree with everything after this. My opinion is we should not surface any configuration to anyone unless desired. The vast majority of configuration options are hidden settings that tweak the way things work. They only need to be surfaced when they are useful, and should therefore always be surfaced in a meaningful way. Anything else should be left in a file without any UI. (When did you last need to change the site timezone. Did you need a UI for this?)

The current method of having extensions subscribe to a delegate to build the System Preferences UI is a very good one — it forces developers to think which fields should be surfaced, and how they should be represented (choosing the appropriate form widget, writing labels and help text). If we attempt to second-guess all of this, we end up with a page that looks like a spreadsheet without any contextual labels or help text.

As there are some extensions that don't store options in the config file but need to be configured, we need to provide a separate section on the preferences page for these cases (think JIT).

Don't think of the Preferences page as the "config file editor", think of it as the "site preferences". These preferences can be stored anywhere (the config being one), and the UI can be anything the developer wants it to be.

[designermonkey]

I disagree with everything after this.

Bit harsh. Do you disagree with the tabs for different environments? I think it's a great approach to handling the changes I'm proposing.

Obviously this is all still up for discussion. I already kind of know that the consensus would be to do like you say and not provide a UI for all options. I was proposing having the prefs page build the UI for extension config from the config.xml file, but if you think it would be more appropriate to leave that to the extension itself, how would you handle multiple environments?

One idea could be to take the layout proposed by the extension, and have the prefs page duplicate it per environment so long as the extensions config is in the config.xml file, leaving the power of the new environment methods in the core. I still want to try and avoid any alteration in how extensions provide their configuration and preferences. We need to have this as a non breaking change for the time being at least.

I know this isn't the final solution, but I definitely feel that having this schema in place fixes many issues. It's now just a 'how do we incorporate it and UXUI it?'

[remie]

Do you disagree with the tabs for different environments? I think it's a great approach to handling the changes I'm proposing.

I disagree with that :D
For security reasons I would strongly be against saving all environment config in a single file. Having username / password of your development database in that file is fine, but TAP credentials should only live on the server they are being used, not in Version Control or visible in the UI.

Application configuration is still something that should be done by System Administrators. This should always be something sticky and nasty to do because you need to be aware that your are changing an important part of the application. If you do something stupid the application will break. So you need to get your hands dirty and it should not be a walk in the park.

[nickdunn]

Bit harsh

Not really. I'm disagreeing, not criticising.

Do you disagree with the tabs for different environments

I do, yep. I don't think the system preferences page should be any more complex than it already is, so I see this environments stuff as pure under-the-hood refactoring, without any impact to the end user. So ideally it would need no UI changes at all. If it does, then we're probably doing it wrong.

If the single file is going to cause problems, then I think a file per environment makes sense. One is the default, and then a per-environment file overrides this, rather than duplicating in each file. This also means you don't need to store production authentication credentials in source control (something which most of my clients would frown upon). Keeping them separate means the production environment file wouldn't be under source control (why would it be?), only the local/development one would be, required to get the site running for each developer. Any per-environment overrides go into the per-environment config file during deployment to each environment.

[remie]

One is the default, and then a per-environment file overrides this, rather than duplicating in each file.

My current implementation (pull request #1117) follows this design pattern.

[designermonkey]

So how does this work then in practice? Where are the preferences saved on each environment?

We version control all our config files, so how would I go about setting per environment configs? Would we have to manually edit the import on each server in the main config file? If that's the case, then this won't work for the workflow we have at the office. We deploy to the servers by fetching the branch, and resetting the repo to that fetched branch, so we would lose that change every time.

One file serves our needs better as the overrides are set by the url of the domain it's being used on. I don't really see an issue having different environments configs in the one file, and also version controlling that config.

TAP credentials

What are these?

Don't get me wrong, the work @remie has done so far is the biggest step for this, and hats off to such an elegant migration under the hood. I'm just trying to keep things simple as I see it.

Not really. I'm disagreeing, not criticising.

I forgot to add the smily face, I meant to joke...

[nickdunn]

We deploy to the servers by fetching the branch, and resetting the repo to that fetched branch, so we would lose that change every time

The trick is not to version control the config file. Version control a config.php.example but not the file itself. The example file would be the canonical "when you check out this repo, these settings get you started", but manually rename this to config.php on each environment, and add it to gitignore, so it doesn't get overwritten.

The above would work well for per-environment settings. You would version control your config.default.xml file, which is used across all environments, but manually create a config.env.xml on dev, staging or production, which is read and overrides any defaults.

That's part of the question — should we have a unique file for each environment that you can version control? That would be good for things like an SMTP hostname which might change between each environment, which can happily go into version control. Or do we go with the "default" and "env" idea, whereby there is one config file with defaults (what we have now), and the developer creates a second override file as and when they need. This avoids the need for an environment switcher, we just test the presence of the env file.

If you version control your config file, then you shouldn't ever want to edit it via a UI on live, because you'd then end up with unstaged changes on a production server. To me that's the same as editing a CSS file on live through the File Manager extension — you should just never do it, since the CSS is version controlled.

[D]TAP credentials

Development, testing, acceptance, production.

[remie]

To me that's the same as editing a CSS file on live through the File Manager extension — you should just never do it, since the CSS is version controlled.

I must admin that I do occasionally do this to do quick fixes on production.

[nickdunn]

Right, but as a last resort. It's not something Symphony should be exposing as good practice.

[brendo]

Most of what I think has already been said.

• I don't think its practical to use tabs to edit different environments,
  you should only edit the settings for the current environment
• Tabs could be used to group related settings (we did this in S3 and I
  think it worked out really well), but as others said, extensions should
  have complete control over the UI (opt in rather than opt out)
• The config groupings can definitely be cleaned up

[designermonkey]

As we're nearly ready to begin on 2.4 work, I just want to wrap this one up ready for integration.

I like how this has gone, the discussion I mean, and I'm resigning myself to the way it is implemented in @remie's pull request.

I would like to suggest though, to not have the local config file linked to the main one at the top of the file, but rather have the php look for it. Also, having a naming convention that follows domains isn't the best approach in my opinion. As the extra config is only going to be on a single machine, it may as well be a standard name to look for.

config.xml
local.config.xml

So the rules for a local config are that:

1. If there is no local config file, write values to the core.
2. If there is a local config file, write values to that instead.

As for extensions and local configs, I suggest that for now, we follow suit and have them use the same rules.

I've also still been playing with ideas re the [https://gist.github.com/3029532](formatting of the config file here). This IMO is something to aim for after we get an implementation working.

So suggestions to move this forward:

1. Leave the schema as @remie has implemented for now, with the addition of a namespace so we can version the xml configs. http://symphony-cms.com/schemas/configuration/1.0.
2. Have the PHP in the configuration class read the config, then search for a local copy to override any specified values.

Next steps after this is in production.

1. Clean up the config groups.
2. Have extensions add configuration to either a separate file or a block extensions section in the core config.

[remie]

I would like to suggest though, to not have the local config file linked to the main one at the top of the file, but rather have the php look for it.

I'm not sure I agree. Why not just leave the inclusion be done by an import tag in the config XML?

[designermonkey]

As I previously stated, if we have a default that is version controlled without a link, my company's approach to deployments would mean editing the default file every time it is deployed.

Also, if it's a fixed filename were looking for, that's always there, it just seems silly to have it linked like that.

It just makes more sense to me.

[remie]

You can have a default file that has an import to "local.xml" for your company. IIRC it will not cause an error if this file does not exist, so there is also no limit in having an import statement in your default config file. We can also provide this as an example in the default config file that ships with Symphony. However, I would not hard-code this in the Configuration class, for there is no need to maintain this. The XML schema provides a generic approach to importing local configuration, let's not cloud that with additional logic in the core.

[designermonkey]

Sold (for now). ;o)

This will be the first feature to make it into 2.4.

[designermonkey]

Re-applied for a clean merge into the integration branch, as so much time had passed.

[jonmifsud]

quick question.. having read through the whole thread.

I would agree with the whole idea of having tracked env configs, however I would like to raise possibly a minor issue. Does this take care of multilingual multidomain setups?

In some cases we have domains running mysite.com/mysite.fr and mysite.local/fr.mysite.local for testing. Would I be able to at least link-up my french to the english version rather then having to duplicate the config for each. Since technically the environment would be the same but not the domain.

Not sure where this is - I know that @remie's work switches to config files but I didn't go through it to see if there is any local configuration files yet. In which case I might as well try to use the integration branch and see how I could handle it

[designermonkey]

How do you do it currently?

• The first step in this is to get the config in xml with the ability to load a single local file to override specific settings.
• Once that's done, the next step is to create an xml schema for config files, and tidy up the config xml structure.

After that, we can look at specifics like multilingual, although I think the entire multilingual approach will be on the cards soon as a separate task.

[jonmifsud]

Currently from our end, we are using either switch statements in the config or different configs per environments. However as of this point I never had to use different configs / language.

Just wanted to raise the issue to make sure its not overlooked, would agree that it could probably be a separate task.

[toledox82]

I was trying use something like @nils-werner idea, insert new parameters to replace, etc, discover about config.php is updated and lost new data I wrote and find this issue.

[designermonkey]

Lot of work is ready to be integrated into integration after 2.3.2 is released, if I remember right, this has been dealt with, so not long now...

[toledox82]

@designermonkey thanks I'm learning about development process of SymphonyCMS and Symphonians Community, to ask less and resolve and contribute more. =)

Thanks.

[designermonkey]

This is now out of scope for Symphony 2 (sadly).

I have already begun preparing a very similar approach for Symphony Next, using schema based XML for configuration.

[nils-werner]

Btw, Laravel supports this out of the box http://laravel.com/docs/install#environments

[designermonkey]

It does, and I'm looking at that, however we will still be using xml to configure Symphony, so using @iwyg's composer package will help configure Laravel with our xml.

Thanks for the reference @nils-werner.