On Pantheon and other platforms (like Heroku), most configuration happens through environmental variables. They're especially useful because they allow straightforward changes to connection information (for things like databases) without changes to the code.

On Pantheon, we run as if the following were in settings.php:

extract(json_decode($_SERVER['PRESSFLOW_SETTINGS'], TRUE));

It would be great (and simple) to have something similar in core without needing a stub settings.php file or core hacks.

Files: 
CommentFileSizeAuthor
#13 D7-1830816-13-environment_settings-do-not-test.patch893 bytesGrayside
#7 interdiff.txt529 bytesSteven Merrill
#7 1830816-7.patch1.2 KBSteven Merrill
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 68,120 pass(es). View
#5 1830816-5-environment_settings.patch907 bytesGrayside

Comments

David Strauss’s picture

Also, it's important that Drupal provide a good installation experience when configuration is injected this way with the database connection information available via the environment. Right now, the installer fails when I test Drupal 8 with a populated settings.php in place that has the proper database connection information. This is a regression versus Drupal 6 and 7.

heyrocker’s picture

Really? I haven't seen that behavior myself and I do this a lot. My typical install experience is to drop and create the database, and reinstall using my existing settings.php. On the first day of BadCamp I did this around 40 times and it worked every time.

David Strauss’s picture

Really? I haven't seen that behavior myself and I do this a lot.

I'll try to catch you on IRC to demo. I'll also double-check that I'm setting the right data; I'm using the same settings.php shim that I used for early Drupal 8 development work.

sun’s picture

Issue tags: +Configuration system
Grayside’s picture

Issue summary: View changes
Status: Active » Needs work
FileSize
907 bytes

Is this still a possibility for D8?

Attached patch is adapted with minor changes from Pressflow 7. (https://github.com/pressflow/7/commit/673fb0bdab618f8989365012149c76b839...).

David Strauss’s picture

I'd ideally like to get it in Drupal 8 *and* Drupal 7. There's no real reason not to backport it, given how much longer D7 will be around.

Steven Merrill’s picture

Status: Needs work » Needs review
FileSize
1.2 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 68,120 pass(es). View
529 bytes

The attached patch fixes an issue - JSON must be decoded as an associative array.

I have tested it manually and this works great for me. I'd also love to see this get into both 8 and 7 for better compatibility with open source PaaS systems like OpenShift.

Steven Merrill’s picture

Mark Sonnabaum also notes that there's some talk of loading a single setting from $_SERVER going on over in #2226761: Change all default settings and config to fast/safe production values, although that's more about dev vs prod.

Steven Merrill’s picture

As an example of how to test this, set your database configuration in your php-fpm.conf as below and hit the installer. That will let you install with a default settings.php file.

env[DRUPAL_SETTINGS] = '{"databases":{"default":{"default":{"driver":"mysql","database":"drupal8","username":"root","password":"","host":"localhost","prefix":""}}}}'

Steven Merrill’s picture

Mark also let me know that we might want to wait and try to see #2016629: Refactor bootstrap to better utilize the kernel land, and then adapt this patch to use it. This code could easily sit inside DrupalKernel::initializeSettings() when that patch lands.

sun’s picture

Title: Support environment-sourced configuration » Support PHP environment-sourced settings/services/configuration via $_ENV
Assigned: heyrocker » Unassigned
Status: Needs review » Needs work

Should be sourced from $_ENV, not $_SERVER.

The primary purpose for hosting providers would actually be to override default definitions in the service container. — But still allowing to override such decisions through a site-specific services.yml file.

To my knowledge, the upstream Symfony Kernel supports this natively. We should borrow/consume that code (identically).

Grayside’s picture

Grayside’s picture

FileSize
893 bytes

Correcting typo from trying and failing to use $_ENV.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.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.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.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.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should 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.