[3.0] Offer the default variant wherever the variant list is built

[albertlast]

Description

Theme::loadVariant() prepends a variant named default to whatever a theme declares in theme_variants:

$this->settings['theme_variants'] = array_unique(array_merge(['default'], $this->settings['theme_variants']));

That is the list a member is actually served from, and data-variant in index.template.php falls back to default when no variant is selected. Two other places build their own list instead, by reading theme_variants back out of a theme's index.template.php with a regex, and neither adds it:

• Admin\Themes::setSettings() — the variant settings on the admin theme page.
• ThemeChooser::pickTheme() — the variant picker a member chooses a theme with.

Both are parsing a different theme's file rather than the loaded one, so loadVariant() has never run over the value they hold.

Where it shows

The picker is the one a member meets. selected_variant is looked up in the list built above, and when it is not found:

Utils::$context['available_themes'][$id_theme]['selected_variant'] = Theme::$current->settings['theme_variants'][0];

So a member whose stored variant is default has the selection silently moved to the first variant the theme declares, and the picker offers no way back to the one they had.

On the admin page the same gap means the "default variant" setting cannot be set to the variant that is in fact the default.

Note on thumbnails

Neither site needs a new image. Both already fall back to the theme's plain thumbnail.png when thumbnail_<variant>.png is absent, which is the path default takes.

The default theme declares no variants at all, so nothing here changes for it — this affects themes that ship variants.

Issues References (Fixes|Related|Closes)

Related to #7933.

🤖 Generated with Claude Code