Following discussion s aboutwith @xjm, @GaborHojtsy, @dawehner, @bircher, @ademarco, and @berdir,@fago, we need to ensure that config overrides (a) don't bleed into configuration when you save it (b) config overrides are used when they should be. This problem has highlighted that it is very easy for config overrides to bleed into configuration.
// Override name in settings.php $config['system.site']['name'] = 'My Drupal site'; // Do something along the lines of: $name = \Drupal::config('system.site')->get('name'); // Put the name in a form or something... \Drupal::config('system.site')->set('name', $name)->save();
This is bad because:
- The code has no control over what is overridden - anything can be overridden in settings.php
- Potentially security sensitive information could end up unintentionally in configuration
- By default return immutable configuration objects from the config factory.
- Allow the developer to get mutable configuration objects from the config factory. Mutable objects should not have overrides.
- Use mutable object where necessary.
- Provide a trait so that forms can easy get mutable configuration objects - but also use runtime config with overrides.
- Config entities when loaded as entities (e.g., via the class's load() method) remain mutable. HEAD already has other code in place to make those override free in config entity forms and listings. From outside those forms and listings, it remains possible to get a mutable, with-overrides config entity and write code that results in override bleed, but this is a less severe problem, since overriding config entity values via settings.php is an extreme edge case: it wasn't even possible to do in D7 at all.
Agree approach Write patch
User interface changes
An incomplete list:
- ConfigFactory::rename() returns the configuration factory and not a config object.
- ConfigFactory::get(), ConfigFactory::loadMultiple(), \Drupal::config(), FormBase::config() return a configuration object that can not be saved or changed.
- ConfigFactory::getEditable() introduced to get editable configuration objects
- New trait
ConfigFormBaseTraitwhich provides a
config()that can return mutable config objects for named configuration. The configuration names are provided by implementations of
Beta phase evaluation
|Issue priority||Critical because this is a blocker for providing a complete solution for. This also has security implications. For example, if you override an API key in production there should be no danger of this being saved back to config.|
|Disruption||Disruptive for core/contributed and custom modules/themes because it will require a BC break. The \Drupal::config(), FormBase::config() will no longer return saveable objects. However the disruption is worth it because of the increased security, reduced fragility of overriding configuration and predictability of the configuration system.|
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 86,263 pass(es). View
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 83,579 pass(es). View
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 83,566 pass(es). View
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 83,537 pass(es). View