Problem
A number of D7 contrib modules use hook_field_(formatter|widget)_info_alter() to add extra "settings" to some widgets / formatters.
They then use form alters on Field UI forms to let admins enter values for those extra settings (and let Field UI store those values along with the "regular" settings), and either entity_view_alter or entity_form_alter to modify the render arrays generated by the render arrays according to those "extra settings".
Typically, this is done to add functionnality not provided by core (e.g: display only the 1st value; use a custom separator between values...). See all modules depending on field_formatter_settings.
The problem is we don't know which module altered those extra settings in, and therefore cannot provide config schema for them (I initially opened #1975112: Config schema mechanisms cannot reflect alterable config trees for this). Thus, those extra settings can't be localized.
Proposed solution
We discussed that with @gabor and @alexpott in Portland, and agreed that putting those 3rd party extra-configuration as part of the formatter/widget "settings" makes no sense. Formatters are classes, this is closed code, you cannot make them use "extra settings" they don't know about.
Those extra properties are not settings for the formatter, they are settings for some 3rd party code that runs after the formatter and alters the result. Storing them along with the formatter settings is just a convenient way to have them automatically saved and loaded back (in D8, in the EntityDisplay config entities).
The typical answer for this in D8 is "store this yourself in your own CMI records / ConfigEntities". If a 3rd party module has params to store about itw own config for a node type, this doesn't go in node.type.[node_type].yml.
In this specific case, however, the logic to get from a view mode to the actual settings to use for this field in this entity bundle in this view mode is a bit complex - see EntityViewDisplay::collectRenderDisplays(). Requiring each 3rd party module that wants to add "extra properties" to store those themselves means they need to reproduce that same logic, and chances are high that they will do it wrong. Plus, the methaphor of EntityDisplay objects is that they contain the whole "recipe" to display an entity, for instance so that they can be altered as a whole.
So the plan would be to add an 'extra' entry, next to 'settings', in each component in EntityDisplay objects. This would act as a free for all dumping ground for 3rd party "settings". The content of this entry would need to be keyed by module name, so that we can build config schemas.
API Changes
- EntityDisplay::getComponent() / setComponent() accept an additional 'extra' entry.
- The config schema for EntityDisplay objects needs to be adjusted accordingly (but HEAD currently provides no config schema for EntityDisplay anyway)
- Field UI probably needs to provide an 'extra' form container in formatter & widget configuration forms, so that the elements altered in there end up saved in the 'extra' entries of each component. It's the responsibility of each module that alters stuff in to key its additions by module name.
- More importantly, this means that widgets / formatter settings do not need to be alterable anymore, and can get out of the plugin definitions and move to a class method. Memory gains here, and also allows us to be more in line with what other plugin types do. Actually doing this affects all widgets / formatters though. Probably for a followup, if at all.
Postponed until
#2136197: Move field/instance/widget/formatter settings out of annotation / plugin definition