Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
In order to autogenerate config forms, expose simple config to REST, improve the config translation system etc. enhancing the config schema system would be really helpful.
Proposed resolution
Additional features:
- Permissions for simple config
- Custom UI widgets for specific elements of the config schema
- Field level access/ simple config level access checking?
- Default values
- Form descriptions: #2913372: Allow forms to be defined in three segments: schema, UI, data
- Allowed values / enum
- Required vs. not required (probably not empty) values
- Many more ...
Comments
Comment #2
dawehnerIt might be quite valueable to have default values.
Comment #3
dawehnerIn order to be able to generate helpful forms, we would need some level of description
Comment #4
dawehnerIf I look at
admin/config/system/site-informationsome of the fields are marked as required, some aren't. On the other hand the config schema doesn't reflect that.Comment #5
amateescu commentedAs far as I understand it, this proposal means that we want to duplicate the existing capabilities of Drupal's field system (mainly
FieldDefinitionInterfaceandFieldStorageDefinitionInterface) by allowing config schema to express all those additional features. Basically, the goal is to be able to write\Drupal\Core\Entity\FieldableEntityInterface::baseFieldDefinitions()in YAML?Which makes me wonder.. why do we need this duplication in the first place?
Comment #6
dawehnerI guess :)
While this issue talks about config schema, conceptually, I think this is more about typed data as a thing. Being able for typed data to provide form widgets is kind of what fago has in mind in https://cgit.drupalcode.org/typed_data/tree/src/Plugin/TypedDataFormWidget too
I personally think typed data is really powerful and exploring more in that area isn't the worst idea :)
Comment #7
dawehnerComment #8
wim leersThis sure seems related to API-First + config entity validation issues that we've been working on!
Comment #9
dawehnerJust added another related issue: #2952037: [meta] Add constraints to all simple configuration
Comment #10
dawehner@fago @gabesullice @wimLeers had a discussion about that, here is a rough summary
Action points
Comment #19
mattew commentedAbout the "required" aspect, the documentation point out that if a property is not nullable, it's required.
But btw I recently encountered an issue with a missing "langcode" property in my config YAML provided into the install folder (I commented the issue about that) which was leading to an imprevisible overwrite by \Drupal\locale\LocaleConfigManager::saveTranslationActive. It was very difficulte to debug, and I think the Configuration Manager should throw an error, or at least a warning, when a config_object value is missing this langcode property.
I was searching for an existing issue about that, to point this out, and I find this one. Maybe somebody could tell me if it's the good place to talk about it? Or should I open a new issue?
Comment #20
mattew commentedI found another issue related the property requirement: #2874793
This issue even show the portion of code which implicitely mark a config as "en" langcode, and is the origin of my particular problem.
Comment #21
mattew commentedComment #24
wim leers→ #3364109: Configuration schema & required values: add test coverage for `nullable: true` validation support + #3364108: Configuration schema & required keys
Already in core — see this for
ckeditor5.plugin.ckeditor5_languagefor example:And just now: #3364506: Add optional validation constraint support to ConfigFormBase should significantly lower the bar to adopt configuration schema-based validation in admin UIs (i.e. forms) for simple config!
Comment #25
wim leersComment #26
joachim commented> Already in core — see this for ckeditor5.plugin.ckeditor5_language for example:
Yes but that's only the option values. It doesn't define the option labels.
The labels are needed for decoupled UIs, and also for translation.
Comment #27
murzThere are several contrib modules that allow building configuration forms directly from the schema:
They work very good and significantly decrease the amount of boilerplate that need to be written!
But the main issue is the strict format of the Drupal Schema format that misses the "description" property, which is crucial for most of the forms to provide good UI.
As a workaround, we can use the
third_party_settingsproperty that is already widely used in different parts of Drupal, so I created a feature request to add this property: #3522197: Allow third_party_settings property in the Drupal Schema format to allow storing metadata and custom module-related data - please join ;-)