Regression: Third party settings for simple config due config schema validation

A bit more digging:

Core's system.schema.yml does not include a third_party_settings key in the system.site section.

ConfigFormBase::validateForm() calls $typed_config->validate(), which prevents the form from submitting.

Hacking a blanket third_party_settings: { } key into core's schema file would at least allow a form submitting the values, but it still would not use my module's schema types or constraints.

Copying my entire schema into the core file would work.

For reference, my module's schema file:

system.site:
  third_party_settings:
    seasonal_paragraphs:
      type: mapping
      label: 'Summer season'
      mapping:
        from:
          type: string
          label: 'Summer season start'
          constraints:
            Regex:
              pattern: '/^\d{4}-\d{2}-\d{2}$/'
              message: "%value must be a date in YYYY-MM-DD format."
            NotNull: []
        to:
          type: string
          label: 'Summer season end'
          constraints:
            Regex:
              pattern: '/^\d{4}-\d{2}-\d{2}$/'
              message: "%value must be a date in YYYY-MM-DD format."
            NotNull: []

My current workaround is creating a dummy form and disabling all form validation (override validateForm and don't call parent::validateForm()). I can even use '#config_target' => 'system.site:third_party_settings.seasonal_paragraphs.to' for form building... as long as I don't validate it...

I don't really get the use case for adding third_party_settings to simple config.

For config entities, it's because you want extra data specifically in THAT entity -- that view, or field, or formatter.

But for simple config, putting some settings in your own new simple config is functionally the same as extending a core or config simple config.

third party settings on simple config was never supported. Automated tests have defaulted to validating config schema for years and would have failed on this.

Per #4, you can alter an existing form and store your config in your own simple config, see for example automated_cron in core: automated_cron_form_system_cron_settings_alter()/automated_cron_settings_submit().

Use case for 3rd pary simple config is per-theme config settings. E.g. Tailwind JIT → module. Theme config is simple config.

2nd reason is it was quick and easy. The amount of boilerplate code required foryour own form is massive, compared to hooks if your module has just a very minimalistic one field config. It is often also is much better UX, if you add your setting to a form your users already know and thematically fits, instead of one more page in the config area.

Yes, theme config is a bit of an edge case, but doesn't change the fact that third party settings never were supported, it just wasn't validated strictly enough. You can store it in your own config, keyed by the theme or a config file per theme, both is possible.

The example I referenced to is a form alter, not a separate form, nothing has to change in the UI for users.

Yes, theme config is a bit of an edge case, but doesn't change the fact that third party settings never were supported, it just wasn't validated strictly enough.

This is a bit confusing statement, given we have prior art for this in multiple core themes, even the newer one's like Olivero and Gin (OK, Gin is not core, but at least part of CMS). But if this is the future direction, shouldn't we mark the corresponding code in shortcut and the themes as deprecated? This is what got me into this in the first place.

I misunderstood/missed the theme settings part initially, I actually wasn't aware that theme settings are supposed* to have third party settings. Sorry. Reopening, there is something off here.

The theme_settings config schema defines third_party_settings, shortcut implements the schema for it. Yet olivero hardcodes it again specifically for shortcut, that seems wrong.

I'd start by removing the olivero specific config schema and then core tests should be unhappy about it based on what you said. I would expect that it should validate and then support additional keys as well, lets see.

The reason I mention "supposed to", is that third party settings are closely related and depending on configuration dependencies. Theme settings files still are simple config/config objects and have no dependencies, so the dependency and cleanup management can't work for them. They really should be config entities, but that obviously is a BC breaking change.

Wouldn't this be solved here: 🐛 olivero.settings config schema is wrong Active ?