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.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | D7-1830816-13-environment_settings-do-not-test.patch | 893 bytes | Grayside |
| #7 | interdiff.txt | 529 bytes | Steven Merrill |
| #7 | 1830816-7.patch | 1.2 KB | Steven Merrill |
| #5 | 1830816-5-environment_settings.patch | 907 bytes | Grayside |
Comments
Comment #1
david straussAlso, 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.
Comment #2
gddReally? 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.
Comment #3
david straussI'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.
Comment #4
sunComment #5
Grayside commentedIs this still a possibility for D8?
Attached patch is adapted with minor changes from Pressflow 7. (https://github.com/pressflow/7/commit/673fb0bdab618f8989365012149c76b839...).
Comment #6
david straussI'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.
Comment #7
Steven Merrill commentedThe 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.
Comment #8
Steven Merrill commentedMark 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.
Comment #9
Steven Merrill commentedAs 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":""}}}}'Comment #10
Steven Merrill commentedMark 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.
Comment #11
sunShould 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.ymlfile.To my knowledge, the upstream Symfony
Kernelsupports this natively. We should borrow/consume that code (identically).Comment #12
Grayside commentedBackport.
Comment #13
Grayside commentedCorrecting typo from trying and failing to use $_ENV.
Comment #27
smustgrave commentedThank you for sharing your idea for improving Drupal.
We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #28
smustgrave commentedSince there's been no follow up in 3+ months going to close out. If someone still wants this feel free to re-open the ticket!