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:

Remaining tasks

User interface changes

API changes

Data model changes

Comments

dawehner created an issue. See original summary.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner at Chapter Three commented
Issue summary: View changes

It might be quite valueable to have default values.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner at Chapter Three commented
Issue summary: View changes

In order to be able to generate helpful forms, we would need some level of description

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner at Chapter Three commented
Issue summary: View changes

If I look at admin/config/system/site-information some of the fields are marked as required, some aren't. On the other hand the config schema doesn't reflect that.

amateescu’s picture

amateescu CreditAttribution: amateescu for Pfizer, Inc. commented

As far as I understand it, this proposal means that we want to duplicate the existing capabilities of Drupal's field system (mainly FieldDefinitionInterface and FieldStorageDefinitionInterface) 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?

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner at Chapter Three commented

I 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 :)

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner at Chapter Three commented
Issue summary: View changes
Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented
Issue tags: +API-First Initiative
Related issues: +#2907163: Split validation-related methods from FieldableEntityInterface into a separate ValidatableInterface, +#2300677: JSON:API POST/PATCH support for fully validatable config entities

This sure seems related to API-First + config entity validation issues that we've been working on!

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner at Chapter Three commented
Issue tags: +Javascript Modernization Initiative
Related issues: +#2952037: [meta] Add constraints to all simple configuration

Just added another related issue: #2952037: [meta] Add constraints to all simple configuration

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner at Chapter Three commented

@fago @gabesullice @wimLeers had a discussion about that, here is a rough summary

  • It would be nice if typed data have some form of handlers/horizontal extensibility for typed data. @gabesullice mentioned the idea of adding additional properties, which is super useful for hierarchical information.
  • For generating forms we would need some more of the metadata defined in the issue summary

Action points

  1. Provide an example of how a json form schema could look like
  2. Based upon that write a RFC which allows us to truely decouple our PHP site from the frontend
  3. Then we would leverage typed data to generate this json form schema, similar to what schemata is doing right now

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mattew’s picture

mattew CreditAttribution: mattew commented

About 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?

mattew’s picture

mattew CreditAttribution: mattew commented

I 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.

mattew’s picture

mattew CreditAttribution: mattew commented
Related issues: +#3204082: Interface translations override config translations on update, +#2874793: Support for required configuration in schema definition

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented
Issue tags: +Configuration schema, +validation
Related issues: +#3364109: Configuration schema & required values: add test coverage for `nullable: true` validation support, +#3364108: Configuration schema & required keys, +#3364506: Add optional validation constraint support to ConfigFormBase

Required vs. not required (probably not empty) values

→ #3364109: Configuration schema & required values: add test coverage for `nullable: true` validation support + #3364108: Configuration schema & required keys

Allowed values / enum

Already in core — see this for ckeditor5.plugin.ckeditor5_language for example:

        Choice:
          - un
          - all

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!

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented
Issue summary: View changes
Related issues: +#2913372: Allow forms to be defined in three segments: schema, UI, data