Drupal Association members fund grants that make connections all over the world.
language.config.XX.configuration_object_name in order to sort the overrides per langcode (XX is the langcode). Configuration translation access is managed with language module and config factory, writing is in locale module and config translation.
This approach still raises a number of problems for us:
- Config file explosion leading to unmanageable configuration stored in files - even if active moves to the DB we still want to have a sensible file structure in staging or a git repository.
- Filename length - we need to keep this less than 255 adding this whooping great prefix on the front does not help
- Because the language override configuration objects have different names schema don't automatically apply
- Depending on how the language configuration is accessed configuration events sometime do fire and sometimes don't. In the configuration translation UI it is accessed both directly though configuration storage and through the config factory.
- Because language is special cased it is hard for other modules to do the same, domain language module would not be able to override the language values, because they are baked in with highest priority. Also there is no real implementation of overrides (outside of tets), so contrib has no real example to follow.
Language configuration overrides should have exactly the same name as the configuration they are overriding. They should be subject to schema validation. They just need to reside in a different directory from active configuration. The patch moves them to a subdirectory
language/XX. Language override configuration should only be accessible through a LanguageStorage service. It should not involve the configuration factory since it is not overridable itself.
The patch completely removes all reference to language from the configuration system. Instead we add a CompilerPass to add objects with implement the ConfigOverrideInterface to the factory. During a loadMultiple the override objects are asked for overrides. All module overrides use the same mechanism (the event has been removed). The compiler pass is better than the events, because on English only sites, then no events are fired, and the compiler pass requires explicit registration, so that will only be added/invoked if needed, not all the time. Reading is performance critical, so this is good. Also, if there is no language, we don't need to handle the special case NULL language is ConfigFactory.
The result is a simpler config factory, replaceable config overrides, cleaner config directories, a real implementation of the config override system, there will only be one way to do overrides and the schema checking will be applicable.
- Cache key length is still an issue, the prefixing is still happening there.
- Make config imports also import the overrides.
- Consider implementing a LanguageConfigOverride class that is similar to Config separate, so it can provide CRUD but no language override for example.
User interface changes
(more to detail in writing)
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 65,255 pass(es). View
|#20||Config overrides and language.png||89.71 KB||Gábor Hojtsy|
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 3-9-interdiff.patch. Unable to apply patch. See the log in the details link for more information. View
PASSED: [[SimpleTest]]: [MySQL] 64,613 pass(es). View