Problem/Motivation

It is difficult to set Drupal's configuration using external systems (i.e. using Docker, etc.).

Proposed resolution

Symfony solved this problem by allowing you to set parameters win Environment Variables:
http://symfony.com/doc/current/configuration/external_parameters.html#en...

Since the only thing that is "runtime configuration" is what is in $settings then I think that's all you should be able to override.

We have more than one variable though, so I propose a syntax like this:

DRUPAL__SOME_VAR = 'some value'

which would get translated into:

$settings['some_var'] = 'some value';

Whatever we do, it should conform to the standard:
http://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap08.html

This gets more complicated if we want to support $config (which has the . character) and $databases which are nested. :/

Remaining tasks

  1. Decide on a syntax
  2. Use the environment variables after what is in settings.php.

User interface changes

None.

API changes

Allows environment variables to be used to override $settings.

Data model changes

None.

Comments

davidwbarratt created an issue. See original summary.

cilefen’s picture

cilefen commented

Forgetting the complicated nesting details for a moment, does $_ENV not work in this context?

davidwbarratt’s picture

davidwbarratt commented

I mean that works fine, but then you have to put globals into your code (when most modules aren't setup to do that); it also doesn't override existing settings.

I think we need a unified way to override "runtime" configuration with environment variables.

Crell’s picture

Crell commented

This is directly relevant for us at Platform.sh, as we provide all of our settings to an application (such as database connections, etc.) via environment variables. Symfony is moving in this direction as well, and Symfony 3.2 has support for reading environment variables directly in the container.

I've been talking around the idea for a while of a PHP-FIG specification around environment variables; the intent being that any application and/or host can follow a common format for "12 factor app" type setups and simplify the glue code that, currently, all host/applications need to produce. (An n*m number of entries is never a good thing.)

So far it's still in the "drum up ideas" stage, but there is some interest in the topic.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

cilefen’s picture

cilefen commented
Status: Active » Closed (duplicate)
Related issues: +#2501901: Allow configuring the environment via an environment variable