[META] Untie config validation from form validation — enables validatable Recipes, decoupled admin UIs …

FYI: The next step forward is happening at #2920678-113: Add config validation for the allowed characters of machine names → ! 🥳

For the ~50 interested people: @phenaproxima proposed to work on 📌 New config schema data type: `required_label` Fixed next. I'm working on 📌 [PP-1] Convert field_storage_config and field_config's form validation logic to validation constraints Postponed 👍

📌 Add config validation for the allowed characters of machine names Fixed landed!

📌 #3360991 changed TypedConfigManager::createFromNameAndData() in 10.1.x Fixed added 10.1 support to the Config Inspector module.

Focus now shifts to:

1. Drupal-core-wide infrastructure: 📌 KernelTestBase::$strictConfigSchema = TRUE and BrowserTestBase::$strictConfigSchema = TRUE do not actually strictly validate Fixed needs review and is committable, with 4 follow-ups to stop ignoring some validation errors and make issues manageable in scope
2. ValidatableConfigFormBase: ✨ Add optional validation constraint support to ConfigFormBase Fixed
3. type: label validation: 📌 New config schema data type: `required_label` Fixed
4. 📌 Configuration schema & required values: add test coverage for `nullable: true` validation support Fixed
5. 📌 Configuration schema & required keys Fixed (blocked by #3364109)
6. last but not least: continue chipping away at 📌 [PP-1] Convert field_storage_config and field_config's form validation logic to validation constraints Postponed (see #14 there), to enable the many -tagged issues to move a lot faster thanks to not having to deal with brittle form validation anymore

IMHO the two next most important problems to tackle (which hopefully @phenaproxima will 🤞), with the most benefit for the ecosystem, would be to:

1. Create a type: langcode, which would benefit both type: config_object and type: config_entity, so would impact 100% of config.
2. Add validation constraints to type: _core_config_info, which again would benefit both type: config_object and type: config_entity, so would impact 100% of config.

Opened ✨ Add a `langcode` data type to config schema Fixed to tackle:

Create a type: langcode, which would benefit both type: config_object and type: config_entity, so would impact 100% of config.

Opened 📌 Add validation constraints to _core_config_info Fixed for:

Add validation constraints to type: _core_config_info, which again would benefit both type: config_object and type: config_entity, so would impact 100% of config

📌 Add validation constraints to _core_config_info Fixed and ✨ Add a `langcode` data type to config schema Fixed have landed, and together they significantly improve on the status quo. Compared to #37:

Next up: continue the plan from #41 (#41.1 (working to get back to passing tests + RTBC after ✨ Add a `langcode` data type to config schema Fixed landed!). In addition to expanding validatability the way I described in #41.3, @phenaproxima has been working on that same problem space (#42 + #43), and I just opened 📌 `type: mapping` should use `ValidKeys: ` constraint by default Fixed 🆕, which will bring a big boost.

P.S.: #41.2 has been RTBC for 2 weeks now! 👍

Update for the plan in #41 from ~1 month ago:

1. ✅ 📌 KernelTestBase::$strictConfigSchema = TRUE and BrowserTestBase::$strictConfigSchema = TRUE do not actually strictly validate Fixed landed, plus all 4 of its follow-ups.
2. 👍 ✨ Add optional validation constraint support to ConfigFormBase Fixed has been RTBC'd by the relevant subsystem maintainer.
3. ✅ 📌 New config schema data type: `required_label` Fixed was re-scoped but is now RTBC, the original scope was handled by 📌 Add validation constraint to `type: label`: disallow multiple lines Fixed
4. 👍 📌 Configuration schema & required values: add test coverage for `nullable: true` validation support Fixed is RTBC.
5. 🚀 📌 Configuration schema & required keys Fixed just became reviewable: #3364108-9: [PP-1] Configuration schema & required keys → .
6. 🏋️ 📌 [PP-1] Convert field_storage_config and field_config's form validation logic to validation constraints Postponed is still making progress, but many of the above issues have a significant impact on it.
7. NEW: 🚀 📌 Follow-up for #3361534: config validation errors in contrib modules should cause deprecation notices, not test failures Fixed just became reviewable, and is a follow-up for #3361534.

and the two suggested next steps have also been completed:

1. ✨ Add a `langcode` data type to config schema Fixed
2. 📌 Add validation constraints to _core_config_info Fixed

Lots of other Configuration schema validation issues → have landed besides those. For example: 📌 Validate config schema compliance of Demo Umami and Minimal profiles, just like we do for Standard Fixed

A fun observation for #3361534: @jibran, maintainer of https://www.drupal.org/project/dynamic_entity_reference → , reported over at #3361534-89: KernelTestBase::$strictConfigSchema = TRUE and BrowserTestBase::$strictConfigSchema = TRUE do not actually strictly validate → that his module started failing tests against 11.x. That means he's probably the first (and likely the only! 😄😮) module maintainer who's running testa against Drupal 11. So, prioritized 📌 Follow-up for #3361534: config validation errors in contrib modules should cause deprecation notices, not test failures Fixed , which now also is reviewable. Added to the numbered list above 👍

Many thanks to everyone involved:

• @borisson_
• @phenaproxima
• @smustgrave
• @penyaskito
• @znerol
• @dww
• @alexpott
• @catch
• @larowlan
• @longwave
• @bnjmnm
• @lauriii

(I hope I didn't forget anyone! 🙈)

Issues created during drupalcon:

• Add validation constraints to olivero.settings 📌 [PP-1] Add validation constraints to olivero.settings Postponed
• Add validation constraints to filter.settings 📌 Add validation constraints to filter.settings Fixed
• Add validation constraints to taxonomy.settings 📌 Add validation constraints to taxonomy.settings Needs review
• Add validation constraints to user.settings 📌 Add validation constraints to user.settings Needs review
• Add validation constraints to dblog.settings 📌 Add validation constraints to dblog.settings RTBC
• Add validation constraints to field.settings 📌 Add validation constraints to field.settings Needs work
• Add validation constraints to media.settings 📌 Add validation constraints to media.settings Active
• Add validation constraints to automated_cron.settings 📌 Add validation constraints to automated_cron.settings Active
• Add validation constraints to image.settings 📌 Add validation constraints to image.settings Active
• Add validation constraints to claro.settings 📌 Add validation constraints to claro.settings Active

#3364108 is still rtbc and #3364109 needs a few more test fixes.

Just in case this is useful, there are three child issues marked as RTBC, that are waiting core maintainer action 😅.
Namely 📌 Add new `EntityBundleExists` constraint Fixed at 2023-10-10, 📌 Add validation constraints to image.settings Active at 2023-11-08, and 📌 Add validation constraints to dblog.settings RTBC at 2023-10-30.

I kinda lost track of this meta 😅 But we've made a TON of progress. Most of the issues listed in #46 have landed. And thanks to ✨ Add a "Validatable config" tests job to GitLab CI to help core evolve towards 100% validatability Fixed having landed yesterday, we won't be making backwards steps anymore, only forwards 🥳

As of today, https://project.pages.drupalcode.org/config_inspector/ looks like this:

Also, the original purpose of this very issue has been unblocked: see the green MR over at ✨ [PP-2] POST/PATCH config entities via REST for config entity types that support validation Needs work ! We absolutely can and should proceed there, even before every config entity type has been made validatable. We now have the necessary infrastructure! 🤘

Yesterday, I've created a new meta issue with a clearer, more holistic view of things: 🌱 [meta] Config validation for a more reliable Drupal + reliable Recipes from the start Active . It splits things 2-ways at a high-level: patterns to apply all across core (with meta/plan issues for those, since those things have dozens of child issues) vs missing infrastructure.

Let's continue there 🙏 This issue has served us well over the past decade, time for a fresh start for the new decade! 😄

Improving discoverability.

Automatically closed - issue fixed for 2 weeks with no activity.