This breaks code that tries to get all instances of SiteConfig like:
```
Translatable::disable_locale_filter();
$all = SiteConfig::get();
Translatable::enable_locale_filter();
```
What was happening was that our populateSiteConfigDefaults method was
getting called before the actual data list the users uses above is
created, so it was re-enabling the locale filter before the
augmentDataQuery function was called on the data list created for the
user. Thus, they'd get a locale-augmented query and only get the
SiteConfig for the current locale, and not all as clearly intended.
Iterating over an array of locales and querying for each one causes tons
of unnecessary queries. This is especially evident when you get up to
hundreds of translations of a page. It makes the CMS admin UI insufferably
slow. This is a little tweak to query for all of them at once instead of
individually.
Even though it is an edge-case, some sites may allow translation groups to be
composed of different classes. In that case, Translatable->getTranslations()
should still work.
Also, this commit adds a helper function for testing two array for equality
where you don't care about the order of the elements. This cleaned up a lot
of copy and paste boilerplate code that was sorting arrays to test.
If the locale-filter was disabled before calling the method, it would be
enabled after calling getTranslations, this commit now only re-enabled
the locale-filter if it was enabled before calling the method...
items from the common_locales in line 1493 return nested array of "name"=>LangName,"native"=>NativeName.
need to make sure to pull the "name" parameter from the array for the $returnMap.
Otherwise was returning:
[Notice] Undefined offset: 0
This builds on 44f8180110, but reverts most of it.
The changeset had a logical flaw where it stored state
on the Translatable extension where it was specific to a FieldList.
This meant side effects when getCMSFields() was called more than once,
such as in the CMSSettingsController template.
Note: We shouldn't need to call getCMSFields() more than once
because its an expensive call, but that's a missing feature
in the template caching layer rather than a problem with the
Translatable extension.
UPDATED: Cleanup and refactoring to make more readable
UPDATED: Translation of siteconfig now better handles singleton(SiteConfig)
UPDATED: Renamed populateSiteConfig to populateSiteConfigDefaults to better reflect its purpose
FIXED: Parameter typing on getStagingSiteConfig
bla
This subtly changes the caching behaviour
where get_one() calls are replaced, results
will be no longer cached. There's no built-in core
way to cache DataList results, so for now we accept
that there's less caching due to this internal change.