Merge branch '4.0' into 4.1

This commit is contained in:
Daniel Hensby 2018-07-13 16:26:19 +01:00
commit ec9281ee02
No known key found for this signature in database
GPG Key ID: B00D1E9767F0B06E
5 changed files with 93 additions and 53 deletions

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

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 -->

View File

@ -0,0 +1,12 @@
# 4.1.3
## 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 -->

View File

@ -39,7 +39,7 @@ class ExtensionMiddleware implements Middleware
}
foreach ($this->getExtraConfig($class, $config, $excludeMiddleware) as $extra) {
$config = Priority::mergeArray($extra, $config);
$config = Priority::mergeArray($config, $extra);
}
return $config;
}

View File

@ -1088,72 +1088,88 @@ class DataObjectTest extends SapphireTest
// Test logical fields (including composite)
$teamSpecifications = $schema->fieldSpecs(DataObjectTest\Team::class);
$expected = array(
'ID',
'ClassName',
'LastEdited',
'Created',
'Title',
'DatabaseField',
'ExtendedDatabaseField',
'CaptainID',
'FounderID',
'HasOneRelationshipID',
'ExtendedHasOneRelationshipID'
);
$actual = array_keys($teamSpecifications);
sort($expected);
sort($actual);
$this->assertEquals(
array(
'ID',
'ClassName',
'LastEdited',
'Created',
'Title',
'DatabaseField',
'ExtendedDatabaseField',
'CaptainID',
'FounderID',
'HasOneRelationshipID',
'ExtendedHasOneRelationshipID'
),
array_keys($teamSpecifications),
$expected,
$actual,
'fieldSpecifications() contains all fields defined on instance: base, extended and foreign keys'
);
$teamFields = $schema->databaseFields(DataObjectTest\Team::class, false);
$expected = array(
'ID',
'ClassName',
'LastEdited',
'Created',
'Title',
'DatabaseField',
'ExtendedDatabaseField',
'CaptainID',
'FounderID',
'HasOneRelationshipID',
'ExtendedHasOneRelationshipID'
);
$actual = array_keys($teamFields);
sort($expected);
sort($actual);
$this->assertEquals(
array(
'ID',
'ClassName',
'LastEdited',
'Created',
'Title',
'DatabaseField',
'ExtendedDatabaseField',
'CaptainID',
'FounderID',
'HasOneRelationshipID',
'ExtendedHasOneRelationshipID'
),
array_keys($teamFields),
$expected,
$actual,
'databaseFields() contains only fields defined on instance, including base, extended and foreign keys'
);
$subteamSpecifications = $schema->fieldSpecs(DataObjectTest\SubTeam::class);
$expected = array(
'ID',
'ClassName',
'LastEdited',
'Created',
'Title',
'DatabaseField',
'ExtendedDatabaseField',
'CaptainID',
'FounderID',
'HasOneRelationshipID',
'ExtendedHasOneRelationshipID',
'SubclassDatabaseField',
'ParentTeamID',
);
$actual = array_keys($subteamSpecifications);
sort($expected);
sort($actual);
$this->assertEquals(
array(
'ID',
'ClassName',
'LastEdited',
'Created',
'Title',
'DatabaseField',
'ExtendedDatabaseField',
'CaptainID',
'FounderID',
'HasOneRelationshipID',
'ExtendedHasOneRelationshipID',
'SubclassDatabaseField',
'ParentTeamID',
),
array_keys($subteamSpecifications),
$expected,
$actual,
'fieldSpecifications() on subclass contains all fields, including base, extended and foreign keys'
);
$subteamFields = $schema->databaseFields(DataObjectTest\SubTeam::class, false);
$expected = array(
'ID',
'SubclassDatabaseField',
'ParentTeamID',
);
$actual = array_keys($subteamFields);
sort($expected);
sort($actual);
$this->assertEquals(
array(
'ID',
'SubclassDatabaseField',
'ParentTeamID',
),
array_keys($subteamFields),
$expected,
$actual,
'databaseFields() on subclass contains only fields defined on instance'
);
}