When you publish a node in the default locale it calls forceChange to make
every field behave as if it has changed. The problem in Translatable is then
it would think that you actually changed the class of the default locale node
and it would force a change on every translation. This was unnecessary when you
have not actually changed the class name. If you have a great deal of
translations this was causing a significant lag when you publish anything in
the default locale.
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.
