third_party_settings in THEME.settings.yml cannot be dependency managed

Hah … I told you I was gonna file this issue for you, but I guess you didn't see that 😭

Merging issue metadata from #3087043: Follow-up for #2352949: themes that include required configuration that depends on modules not handled correctly and closed it.

Manually tested with #3086435-13: Add automated test coverage for Claro. This core patch makes that patch pass tests. 🥳

so I'm not sure we need to add a test here.

If we commit this, then #3086435-13: Add automated test coverage for Claro can become part of Claro, and then once Claro lands in core via #3079738: Add Claro administration theme to core, we'll have test coverage for this.

The only alternative way to add test coverage for this is to add a new test-only theme with required configuration that depends on a module. That seems excessive?

Tempted to RTBC. Thoughts?

I grepped core for theme_get_setting('third_party_settings and Shortcut is the only example using this pattern.

My initial reaction to reading #10 and #11 is that we should do #11.4, except maybe flip the name order to THEME.MODULE.settings.yml, and then maybe introduce either a new function (e.g., theme_get_module_specific_setting()) to read from it, or add an optional $module parameter to the existing theme_get_setting() function.

However, I don't think we can break BC of the existing third_party_settings.shortcut.module_link theme setting. To continue to handle that specific case, I wonder if we should fix shortcut_themes_installed() and shortcut_install() to instead of hard-coding 'seven', to invoke an alter hook for determining which themes to apply that logic to. I'm suggesting an alter instead of some other hook, because we already have ThemeManager::alter().

#10 changed the component of this issue, so is the title of this issue still what we want? Or is the issue something more like "third_party_settings in THEME.settings.yml cannot be dependency managed"?

Actually, just changing the title. Feel free to change it back if we want to rescope the issue to just testing setup fixes.

Let's take a step back.

1. Why do we even have this problem? Because the Shortcut module wants to have theme-specific settings.
2. Why does it have theme-specific settings? Because Shortcuts only make sense for the admin theme. A third party setting in a theme's config is one way we can do that.
3. But there are many other ways we could do this:
   1. make admin themes have a shortcut-integration-supported: true key-value pair in their *.info.yml file
   2. add configuration to shortcut.settings.yml that allows this to be enabled per theme
   3. don't make this configurable at all, and instead make this happen automatically for all admin themes
4. Are there other modules that have a similar configuration need?

Long story short: let's not spend a lot of time on building somethign complex if it will only ever be used by a single module that is infamous for its weird architecture.

Just tripped on this with the gin admin theme. Its causing config schema errors now on gin admin theme.

#15 3.2 sounds like the easiest fix to me for storing such information. I don't think we should hardcode it on admin themes, that's not what this is about. there could be sites where having this in the frontend theme could be useful and it's also not something that the theme can/needs to decide on.

THEME.settings.yml is simple config, and other modules shouldn't mess with simple config of other modules or themes.

Patch for 10.1.x.

I think I've got a related problem: My module has theme-specific settings. Previously I just stored my modules config settings in the root of theme.settings.yml. Inspired by the shortcut module, I now wanted to clean this up and move it into third party settings. Basically I wanted to update my config from

third_party_settings:
  shortcut:
    module_link: true
tailwind_jit:
  compile_html_requests: true
  html_input_file: 'foo.css'
  compile_ajax_requests: true
  ajax_input_file: 'bar.css'

to a proper schema

theme_settings.third_party.tailwind_jit:
  type: mapping
  label: 'Tailwind JIT settings'
  mapping:
    compile_html_requests:
      type: boolean
      label: 'Compile HTML requests'
    html_input_file:
      type: path
      label: 'Uncompiled CSS input file for HTML requests'
    compile_ajax_requests:
      type: boolean
      label: 'Compile Ajax requests'
    ajax_input_file:
      type: path
      label: 'Uncompiled CSS input file for Ajax requests'

and proper third party settings

third_party_settings:
  shortcut:
    module_link: true
  tailwind_jit:
    compile_html_requests: true
    html_input_file: 'foo.css'
    compile_ajax_requests: true
    ajax_input_file: 'bar.css'

The form hook is something like

function tailwind_jit_form_system_theme_settings_alter(&$form, FormStateInterface $form_state, $form_id = NULL) {
  $form['third_party_settings']['tailwind_jit'] = [
    '#type' => 'details',
    '#open' => TRUE,
    '#title' => t('Tailwind CSS Just-in-time compilation'),
    '#tree' => TRUE,
    '#parents' => ['third_party_settings', 'tailwind_jit'],
  ];
  $form['third_party_settings']['tailwind_jit']['compile_html_requests'] = [
    '#type' => 'checkbox',
    '#title' => t('Compile HTML requests'),
    '#default_value' => theme_get_setting('third_party_settings.tailwind_jit.compile_html_requests', $themeToBeConfigured),
  ];
  /* ...more form elements here... */
}

This does not work correctly, there are two problems:
1) The schema is not used/validated, the boolean value is still stored as (int) 0 / 1 and not as (bool) true / false
2) When submitting the form, it saves all my values, but wipes the existing config from shortcut module.

Reading @berdir's comment, is shortcut a bad example? Should I avoid third party settings for themes at all?

Update:

Tested the new #config_target instead of #tree and #default_value, but also does not work. It reads the existing values, but on save the schema validation seems to fail ('tailwind_jit' is not a supported key, but do I do have a schema file)