Allow adding dynamic configuration schema

Created on 26 July 2019, almost 5 years ago
Updated 22 March 2024, 3 months ago

Problem/Motivation

When we want to add a dynamically determined key to typed data scheme via hook_config_schema_info_alter, we get an exception that adding keys is not allowed.

Proposed resolution

Add a hook_config_schema_info_build.

(Paralleling hook_library_info_build / hook_library_info_alter)

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

✨ Feature request
Status

Needs work

Version

11.0 πŸ”₯

Component
ConfigurationΒ  β†’

Last updated about 7 hours ago

Created by

πŸ‡©πŸ‡ͺGermany geek-merlin Freiburg, Germany

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request β†’ as a guide.

    This seems more like a feature request.

    Still wondering if it's a valid use case but may help to have a test case to show the issue.

  • πŸ‡©πŸ‡ͺGermany tstoeckler Essen, Germany

    So I think that on its own the use-case is definitely valid and it would things a fair bit easier for certain advanced use-cases to be able to use PHP to produce the config schema. The reason that we explicitly disallow this at the moment (and @GΓ‘bor Hojtsy (or anyone else) please do correct me if I'm misremembering) is that for translatability you need to be able to determine the config schema statically. I.e. you need to be able to check out any version of drupal core or a contrib module via git and be able to say which parts of any config are translatable. And - while it's certainly not super trivial - that's currently possible, even with a very complex view you are able to determine exactly which key is translatable and which is not. And you can do that with potx β†’ (which in fact does exactly that, as far as I know) but you can also that with Python or Go if you are so inclined. And as soon we introduce dynamic schema into the mix that is no longer possible. So as far as I can tell this is "won't fix", unfortunately, but I surely may be missing something or not considering other factors.

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    Totally agree that this makes sense and is still super valid. πŸ› Fix config schema Fixed is one of many good examples :)

  • πŸ‡ΊπŸ‡ΈUnited States Dave Reid Nebraska πŸ‡ΊπŸ‡Έ

    I had a use case where the plugins were being dynamically generated from YAML files, and while an incredibly generic config schema could be used for all of them, we wanted to provide the specific config schema for each one based on the YAML plugin definition, instead of having to duplicate both the YAML plugins and the config schema for each individual one. I think there's still a valid use case for this.

Production build 0.69.0 2024