Rivet-specific settings are missing from subtheme settings forms

Generated with the help of an LLM.

Problem/Motivation

Rivet-specific settings are no longer added to the settings forms of Rivet subthemes.

The regression was introduced in Rivet 1.2.0 by the object-oriented theme-settings conversion in #3636231: 'Class "rivet_form_system_theme_settings_alter" does not exist' error. The converted form_system_theme_settings_alter implementation only continues when the form's configuration key is exactly rivet.settings:

if (($form['config_key']['#value'] ?? NULL) !== 'rivet.settings') {
  return;
}

A subtheme's settings form uses its own configuration key, such as my_subtheme.settings. The alter hook therefore returns before adding Rivet's settings and submit handler.

This affects both direct Rivet subthemes and descendant themes whose base-theme chain includes Rivet. The following controls are missing:

• Site name
• Subtitle
• Home breadcrumb behavior
• Footer color variant
• Privacy notice URL
• Sidebar border
• Global page width
• One-column content width

The recommended way to use Rivet is through a subtheme, so most consuming sites cannot manage these settings through their active theme's settings form.

Steps to reproduce

1. Install Rivet 1.2.0 or 1.2.1 on a supported Drupal version.
2. Create a theme whose *.info.yml declares base theme: rivet.
3. Enable the subtheme.
4. Visit /admin/appearance/settings/MY_SUBTHEME.
5. Observe that the form contains Drupal's generic theme settings but none of Rivet's header, breadcrumb, footer, sidebar, or layout settings.
6. Visit /admin/appearance/settings/rivet and observe that the Rivet-specific settings are present there.

Expected result: Rivet-specific settings are available on the settings form for Rivet and every installed Rivet subtheme. Values submitted through a subtheme form are saved to that subtheme's configuration.

Actual result: Rivet-specific settings are only available for the base theme's rivet.settings form.

Proposed resolution

Derive the target theme name from the form's *.settings configuration key, then use the theme extension list to determine whether the target is Rivet or has Rivet in its base-theme chain.

Continue altering the form only when:

• The configuration key is a string ending in .settings.
• The corresponding theme exists.
• The theme is Rivet or its resolved base_themes contains Rivet.

For example:

$config_key = $form['config_key']['#value'] ?? NULL;
if (!is_string($config_key) || !str_ends_with($config_key, '.settings')) {
  return;
}

$theme_name = substr($config_key, 0, -strlen('.settings'));
$themes = $this->container->get('extension.list.theme')->getList();

if (
  !isset($themes[$theme_name]) ||
  ($theme_name !== 'rivet' && !isset($themes[$theme_name]->base_themes['rivet']))
) {
  return;
}

This restores Rivet's settings for direct and indirect subthemes without adding them to the global settings form or to unrelated themes.

Remaining tasks

• [x] Reproduce the missing subtheme settings
• [x] Identify the regression in the settings-form guard
• [x] Prepare a first-pass fix
• [ ] Add functional coverage for a generated Rivet subtheme's settings form
• [ ] Verify that submitted values are saved to the subtheme's configuration
• [ ] Verify that global and unrelated theme settings forms remain unchanged
• [ ] Test against the supported Drupal 10 and Drupal 11 versions
• [ ] Review and merge

User interface changes

Restores the existing Rivet-specific controls on Rivet subtheme settings forms. No new settings are introduced.

API changes

None.

Data model changes

None.