Spin off fromand .
Currently, the collection of available "settings" for a field/instance/widget/formatter are part of field type/widget/formatter plugin definition (in annotations), and are thus alterable like the rest of the plugin definition.
In D7, a lot of contrib modules have used that to add new "settings" of their own, that thus get conveniently saved and loaded along field/instance/widget/formatter definitions.
In current core D8, content_translation does the same to add its 'translation_sync' field setting, applicable to all field types.
Problem: there is no way to provide config schema for this (detailed explanation / discussion in
This was discussed back in Portland, and this is now a major issue because relies heavily on config schema info.
Summary of the discussion in Portland:
- A config entity cannot hold properties it doesn't know about, because then it cannot provide a schema for them. The rule is : "if you have additional settings of your own to store about my config entity, store them yourselves in your own config records for which you can provide a schema".
- More specifically, the config schema for the 'settings' part of a field/instance/widget/formatter configuration is statically provided by the module providing the field type/widget/formatter, and the schema mechanism doesn't let any other 3rd party code provide additional schema info about it. We cannot ask *all* field type modules to provide schema info about the 'translation_sync' property that *might* be present in field.field.*.yml CMI files in case c_t.module is enabled.
- Those "extra settings" are in fact not settings for the plugin anyway, since the plugin class won't suddenly and magically know and use them. They are actually settings for 3rd party code (typically implementations of hooks fired when after the plugin did its job), and storing them in 'settings' is only a convenient way to have free storage and loading. But we just can't support that in D8 anymore.
[edit: is here to bring this functionnality back for widgets & formatter settings in EntityDisplay config entities, in a structured way that allows config schema - see over there why it makes sense for widgets & formatters]
- The set of supported field/instance/formatter/widget settings, should *not* be alterable, and we should probably remove them from the plugin definitions (that's what makes them alterable) and into static methods in the plugin classes (that's how Views always did it).
- In the case of content_translation, it means 'translation_sync' should not be an altered-in field setting, but a separate piece of config, associated to a given [entity_type, bundle, field_name], tracked and managed by content_translation whichever way it sees fit.
Coding happens in 2136197-settings-annotations-remove branch