Altering in random settings to a config entity is not a supported way of extending a configuration entity. The entity will not know how to deal with them, we cannot provide configuration schemas for them, if modules are disabled, remains of prior unattended settings may remain, the dependency management is broken in this case, and so on.
The problem with fields is worst. Examples of modules altering in random entity settings for fields include Content translation (the field_sync setting for translatability), Field permissions module, etc. Node already have some way to store third party settings but need unification, that is handled in.
- Add a generic ThirdPartySettingsInterface, that config entities may implement to support third party settings. Implement this in FieldConfigInterface. Other config entities may implement this later on.
- Add common implementation for this in ThirdPartySettingsTrait, so config entities can take a common implementation for easier developer experience.
- The trait implements settings storage for key/value pairs for each third party module separately under a third_party_settings key in configuration. Add configuration schema coverage for this based on dynamic key typing, so eg. content translation module can add schema for its setting.
- Add all modules that provide third party settings as dependencies to the configuration entity dependency list.
- Remove obsolete code and test workarounds. Add tests.
The solution is a general approach that other configuration entity types may use. Eg. this will be used inas well.
User interface changes
Field settings schemas changed to include third party settings. New ThirdPartySettingsInterface, ThirdPartySettingsTrait.
|#141||interdiff.txt||1.47 KB||Gábor Hojtsy|
|#141||2224761.141.patch||30.54 KB||Gábor Hojtsy|
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 75,560 pass(es). View
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 75,567 pass(es). View
|#131||interdiff.txt||1.79 KB||Gábor Hojtsy|