Laravel style config system?

[Patrick Nelson]

Does SilverStripe have the ability to easily roll out configuration which varies by named environment which can still be committed to the repository? For example, I understand that I have the ability to define constants in _ss_environment.php. The problem there is that it is pretty inflexible and requires more maintenance than simply committing directly to a file which will be immediately available upon deploy, e.g. conf/widget.php and conf/test/widget.php and conf/dev/widget.php which would expose configuration parameters such as "widget.foo" which would vary between prod, test and dev automatically. Another major advantage to this approach is the ability to provide arrays (since constants can only evaluate to scalar types) as well as even closures.

Thoughts? Would SS be open to this sort of internal improvement for v4? Or, better yet, is there already a module already available that provides this sort of functionality? I'd like us to consider using the uncommitted code strictly for things that don't belong in the repository (like credentials).  I couldn't find much here about committed per-environment configuration. 

[Patrick Nelson]

For future reference, I think I found my answer here via YAML config using a header key "Only" with a sub-key of "environment: [name]". 

https://docs.silverstripe.org/en/3.2/developer_guides/configuration/configuration/

Granted, I don't like it, but I suppose it'll get the job done. It's not as concise as the solution I proposed above, but it may be faster (technically) since I know YAML config is cached. But at least I can now clearly denote specific config for specific environments by creating separate *.yml files such as "test" or "prod".

[Will Rossiter]

If all you need is the YAML API then its possible to do this with app/config/production .yml and use exclusionary rules

https://docs.silverstripe.org/en/3.2/developer_guides/configuration/configuration/#exclusionary-rules

—

Only:

  environment: live

—

…

-- 
Will Rossiter
Sent with Airmail

[Nicolaas Thiemen Francken - Sunny Side Up]

In case you want, for example, test your local copy in live mode, but still keep some of the configs in dev mode then you can put the following in your local _ss_environment.php file:

define("my_dev_machine", true);

and then in your yaml file you put:

-----

Only:

  constant_defined: "my_dev_machine"

-----

Bar: 

  foo: 'bla'

We used this approach extensively for a site that runs on two live machines (each with their own theme / settings, etc...). 

 

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Nicolaas Thiemen Francken
  www.sunnysideup.co.nz

  phone: +64221697577

[Florian Thoma]

I would like to propose a change in how the environment config is handled.

My suggestion is to remove (of course deprecate first) the _ss_environment.php file and replace it with a yml config file, i.e. _ss_environment.yml. That yml config file should also sit in website root or above, same as the current _ss_environment.php.

I found that there is only the $_FILE_TO_URL_MAPPING parameter that only works when set in _ss_environment.php. Every other setting can also be set in the normal php config or yaml.

I think a yml approach for the environment config would be the most concise solution. That way also i.e. API urls and keys and other credentials that are different for each environment could be handled without having to check them into GIT or make configuration of a new environment a nightmare.

(Just as a side note: To have that same functionality using the php config I have copied the env loading code from framework/core/Constants.php into my mysite/_config file to load an _environment-config.php that contains all the php config stuff for that environment. Because I use the same code to load the _environment-config.php file it can sit along the _ss_environment.php fil in or above the website root.)