tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-10-22 14:05:37 +02:00
Code Issues Projects Releases Wiki Activity

DOCS Update docs to reflect true config merge priorities

Browse Source
This commit is contained in:
Daniel Hensby 2018-07-12 01:09:17 +01:00
parent 4acec33562
commit d80ef3d9e6
No known key found for this signature in database
GPG Key ID: B00D1E9767F0B06E
2 changed files with 14 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/en/02_Developer_Guides/04_Configuration/00_Configuration.md
View File

@ -153,12 +153,12 @@ the result will be the higher priority false-ish value.
The locations that configuration values are taken from in highest -> lowest priority order are:
- Any values set via a call to Config#merge / Config#set
- Runtime modifications, ie: any values set via a call to `Config::inst()->update()`
- The configuration values taken from the YAML files in `_config/` directories (internally sorted in before / after
order, where the item that is latest is highest priority)
- Any static set on an "additional static source" class (such as an extension) named the same as the name of the property
- Any static set on the class named the same as the name of the property
- The composite configuration value of the parent class of this class
- Any static set on an "additional static source" class (such as an extension) named the same as the name of the property
<div class="notice">
It is an error to have mixed types of the same named property in different locations. An error will not necessarily

12
docs/en/04_Changelogs/4.0.5.md Normal file
View File

@ -0,0 +1,12 @@
# 4.0.5
## Notable changes
Fix [#7971](https://github.com/silverstripe/silverstripe-framework/pull/7971) introduces a subtle change of behaviour
to how `Config` settings are prioritised. In SilverStripe 4 there was a change where `Extension` objects took the
highest importance when determining Config values; this was deemed to be unexpected and unintuitive as well as making it
cumbersome and difficult for developers to override module defaults defined in `Extension`s. This change reverts
behaviour to that of SilverStripe 3 where `Extension` instances are of lowest importance and are used only to set a
default value. If you rely on your `Extension` or module providing an overriding config value, please move this to yaml.
<!--- Changes below this line will be automatically regenerated -->