Contextual configuration in core: do we want it and can we do it?


Working on the contextual override of configuration objects (in the context of Domains), and I want to build a user interface (UI). I had intended to use Config Translation as a model, but ran into a few issues:

* Config Translation shows us that schema mapping is critical to build a UI for config overrides. Building the form requires the schema.

* Schema has some of the required metadata for building this form. The rest (access control, for instance) is stored in the route.

* Config Translation handles config entities, config objects, and field config. The required metadata for routes and access control (used to build the list of translatable strings) can be derived for config entities and field config, but not for config objects.

* Config objects, therefore, have their own special mappers (*.config_translation.yml), whose sole purpose is to map Routes (and therefore paths and access control) to Schemas, which allows the Config Translation UI to work.

* The support for config objects in those *.config_translation.yml files is limited to string data types, because that's what Config Translation cares about.

Suppose, however, the following use-case for a site:

* When Hungarian is the default language context, timezone should be CEST (UTC + 1:00); when Japanese is the default language context, timezone should be JT (UTC + 9:00).

Right now, you cannot discover the proper data to use to recreate:

* A route to the default configuration form for

* The schema used by that form -- though that is potentially addressed in

* Access control rules that should be applied to that form.

* A way to discover config objects that are not strings (like timezone).

So the question for core is: Do we can about the ability to do these things? If so, what changes are necessary to enable them?

Session Track

Core Conversations

Experience Level


Drupal Version

When & Where

Tuesday, 27 September, 2016 - 15:45 to 16:45
Liffey Meeting 4 | New Relic