Objective
-
$GLOBALS['conf']['container_yamls']
allows settings.php to specify additional site-specific service YAML files. -
#2241633: Simplify site-specific service overrides removes the need to set that variable, and simply discovers a
$conf_path/services.yml
file automatically, if it exists. -
There is not really a use-case for manually specifying additional service YAML files —
Except of possibly kernel-environment-specific overrides.
Proposed solution
-
Remove the global
$GLOBALS['conf']['container_yamls']
variable + all references to it (none as of today). -
Make
DrupalKernel
automatically discover a kernel-environment-specificservices.$env.yml
file, which is able to override theservices.yml
definitions:if (file_exists($site_services_yml = conf_path() . '/services.yml')) { $this->serviceYamls['site'][] = $site_services_yml; } $env = $this->getEnvironment(); if (file_exists($site_services_yml = conf_path() . "/services.$env.yml")) { $this->serviceYamls['site'][] = $site_services_yml; }
→
$conf_path/services.dev.yml
adds to or overrides$conf_path/services.yml
Comment | File | Size | Author |
---|---|---|---|
#5 | drupal8.site-env-services.5.patch | 1.87 KB | sun |
#3 | drupal8.site-env-services.3.patch | 775 bytes | sun |
Comments
Comment #1
sunBlocked on #2241633: Simplify site-specific service overrides
Comment #2
sunClarifying issue title.
Comment #3
sunSimple. :-)
Comment #4
sunOne global/settings variable less to document. :-)
Comment #5
sunAdded test coverage.
This is RTBC from my perspective.
Comment #6
dawehnerservices.$env.yml is certainly a great idea.
One thing we might have to take care about are hosting providers. In HEAD they can just ask people to put that container_yaml bit into the settings file or actually just expose settings.whatever.php for the developer.
With this patch you have just one yml file so it might be problematic to enable memcaching etc. without interact with developer code in git repos.
Comment #7
tstoecklerIf we stick with this new approach I think this should be postponed on #2229011: Tests are no longer modifiable and the implementation re-considered after that.
Thoughts?
Comment #8
sun@dawehner: For hosting providers, we rather want to look into native support for
$_ENV
(as in upstream), which seemingly is the goal and purpose of #1830816: Support PHP environment-sourced settings/services/configuration via $_ENV@tstoeckler: Neither this change nor the initial/previous change of #2241633: Simplify site-specific service overrides is related to tests in any way. All site-specific overrides MUST NOT leak into any test environment.
The test change in this patch might have caused confusion — it only exists to prove that a (regular runtime) kernel (re)build does actually consume an additional environment-specific
services.$env.yml
file from the site directory.However, this is not meant to be a pattern to override services for test environments. Any attempt to base such a mechanism on this facility here would not work either way, since the kernel environment (intentionally) varies for each test base class.
Comment #9
jibranRelated #2315613: Add a development.services.yml for development
Comment #11
jhedstromNeeds an IS update if there's anything left to be done (the global is gone).
Comment #22
smustgrave CreditAttribution: smustgrave at Mobomo commentedGoing to close as outdated since this has been in PNMI for 6 years without an update
If you feel this is still an issue please reopen. After searching for any duplicates