Does configuration belong to  site, a specific environment or to specific modules? Originally in Drupal 8, configuration was designed to be ‘owned’ by the site. However, the amount of config related contrib modules and initiatives on drupal.org are proof that there are many use- and edge cases regarding the place of configuration in Drupal 8.

For this session I would like to discuss yet another use case I’ve come across in my own projects and to which I’ve found that different contrib modules have provided similar solutions: configuration saved in fields instead of configuration entities.

Configuration in Drupal 8 is essentially nothing more than a associative, multi-level, array of settings, mostly provided by plugins, that are saved to ‘configuration entities’. Instead of saving those settings to configuration entities, we might also save them to a field of the type Map. Commerce and Views Reference Field are in fact two examples of modules that do just that.

Should we provide a standard solution to prevent module builders from building different solutions to the same problem? Should we try and apply the same rules to configuration saved in fields as we apply to configuration entities: making them ‘typed’ (mapping values to data types), translatable and exportable?

I’ve been working on a proposal (work in progress):  https://github.com/nuez/plugin_configuration_field. With this session I hope provide an overview of how configuration works in Drupal 8, how it would work saving configuration to fields, but mainly to open a debate and learn from the feedback of the audience.