Configuration

I apparently released the Drupal configuration schema cheat sheet 7 years ago (wow!) to help people adopt the then new format to describe configuration structure. I keep getting questions and requests about it, so decided to make a major update to it now and bring it to the present day for Drupal 9.

Download Configuration Schema Cheat Sheet 2.0

Updates from 1.5 (April 2015) include:

• Double the pages, more extensive examples and pointers to core definitions
• Includes description of config ordering introduced with Drupal 9.3
• Documents how to pick schema keys for various use cases, such as config entities
• Documents where to put the schema files and when to use multiple
• Explains common string subtypes and recent additions to base scalar types
• Contains a whole section on translatability
• An entire new section to explain basics of mappings and sequences, the most common request
• Explains potential of string keyed sequences 4 or so times, so hope it goes through :)
• Suggests to use common mapping subtypes like mail and text_format
• Covers ignore and undefined
• Adds a whole new intro to dynamic typing to make the examples easier to understand
• Makes all dynamic examples contain all definitions instead of abbreviations for easier understanding
• Uses the same data to explain the [%parent] and [childkey] dynamic typing, to show the differences better
• Cites various common core extension points, such as third party settings on themes and config entities
• Explains advanced properties such as nullable lists
• Updates test base class names for Drupal 9

I regularly receive feedback about people using the cheat sheet, so I hope this will help make config schema somewhat easier to grok. Improvement suggestions still welcome!

Kudos to Rene Bakx for his most recent questions that tipped me over to update the sheet.

After over a month of concentrated work, Drupal 8 was ready today to finally flip the switch and enforce strict configuration schema adherence in all TestBase derived tests in core. See the announcement in the core group.

If you are a Drupal 8 contrib developer and provided some configuration schema earlier (or you integrate with an existing core system like blocks, views, fields, etc.) then your tests may now fail with configuration schema errors. Unless of course all your configuration schema is correct: #highfive for you then.

Otherwise I thought you'll have questions. There is of course the existing configuration schema documentation that I helped write. However if you are a visual person and want to get an understanding of the basics fast, I thought a cheat sheet would be a great tool. So sat down today and produced this one in the hopes it will help you all! Enjoy!

Please provide feedback for improvements in the comments, and I'll update the sheet as appropriate.

Up to date as of October 29th, 2015.

We learned how configuration translation works on the conceptual level and through the Drupal 8 built-in user interfaces in the previous article of the series. In this article, we'll cover how can developers integrate with configuration translation.

Explaining the structure of configuration

We used your main site configuration file as an example in the previous article. Let's review that again (system.site.yml):

There are clearly some translatable elements here. Which ones? Well, at least the site name and slogan would be. How would Drupal know though? There is nothing in this file to tell Drupal about that. There is also no code in handling this configuration that needs to deal with that. We wanted to introduce language support in the most transparent way. Instead Drupal supports a static description format to describe the structure of configuration, that we call configuration schema.

Up to date as of October 29th, 2015.

After a long 8 months break in the article series, we are back to talk about configuration translation basics. Why the long break? Well, both the configuration and content system was in heavy development with changes and I did not want to get you content that would be quickly outdated. In the meantime Alex Pott also posted a great set of articles titled Principles of Configuration Management Part 1 and Part 2 which serves as great introductions. We’ll cover configuration translation first because that is more baked.

The Drupal 8 configuration system is a boon for language

As I wrote in the previous article in the series, configuration is now encompassing lots of settings that were variables or used custom settings storage in Drupal 7. The biggest value for non-English and multilingual sites in Drupal 8 of the configuration changes is that now a common system is used to manage your site name, email text settings through to views, field settings, entity form displays, etc. We can introduce language and translation support in a way that modules will need to plan with. It is not just an optional contributed add-on but a core feature.