Admin theme preferences (mirror the frontend theme selector)

[e107help]

Summary

Give the admin area its own theme selector and preferences, the way the frontend theme already works: an admin can pick which admin theme is active and configure its options, instead of the admin theme being effectively fixed. This builds on the custom-admin-theme unblock and pairs well with a CSS-variable-driven framework.

Split out of #5686 per @Jimmi08's scoping.

What this covers

• An admin-facing UI to select the active admin theme from the installed themes that provide an admin face (the frontend already does this through the Theme Manager's "set as main" flow; the admin half currently only renders a button for allowlisted themes at e107_admin/theme.php L1160-1162).
• Per-theme admin preferences/configuration, mirroring how frontend theme preferences are stored and applied.
• @Jimmi08 notes this is especially natural with a CSS-variable-based framework (tabler.io, being Bootstrap 5 underneath, exposes its look entirely through CSS variables), so admin-theme appearance could be tuned from admin preferences without deep template edits.

Dependencies

• Requires the custom-admin-theme unblock first (otherwise there is nothing to select).
• Benefits from, but does not strictly require, the BS3->BS5 migration; the preference surface is framework-agnostic.

Acceptance

• Admins can choose the active admin theme from a preferences/selector UI, like the frontend theme selector.
• Admin theme preferences persist and apply.
• The default admin theme is unchanged for sites that do not touch these settings.

---

Type: Feature. Triage Status: Backlog. Priority: Low. Split from #5686.

[e107help]

Zdravím @Jimmi08, and thanks for the nudge. You asked what I'd find once I started digging into admin theme preferences. I've traced it end to end now, and the short version is the encouraging one: most of the machinery is already in core, it's just wired to the frontend theme only. Making the admin theme configurable is largely a matter of letting the admin side reuse what the frontend side already does.

Here's the dig, then a recommended direction for @Deltik to steer.

What's already there

When you hit "set as main" on a frontend theme, themeHandler::setTheme() writes a whole bundle of prefs and initialises the theme's own settings into their own database row (theme_handler.php L3098-L3121, config init at L3123-L3157). A theme exposes those settings by shipping a theme_config.php with a theme_config class, discovered by loadThemeConfig() (L2346-L2398). Same convention your frontend themes already use for their settings tab.

Those settings store through e_theme_pref, which already supports a per-row suffix: getThemeConfig('mytheme', 'admin') would write to a theme_mytheme_admin row with no schema change at all (pref_class.php L1047-L1059, passed through by e107_class.php L1475-L1491). So the storage we'd need is sitting there unused.

The three gaps

1. The settings tab is hard-gated to the frontend. The "Preferences" tab renders only in RENDER_SITEPREFS mode, never RENDER_ADMINPREFS (theme_handler.php L2605-L2608; modes at L1516-L1517). So an admin theme's theme_config would never show; in admin mode you only get the CSS-skin picker, the adminstyle dropdown and the adminpref checkbox (L2800-L2836).

2. The pref helpers hardwire sitetheme. e107::getThemePref() / setThemePref() always resolve the current theme as the frontend one (e107_class.php L1507-L1524). No admin-scoped reader/writer, so a theme can't cleanly read its own admin settings at render time.

3. setAdminTheme() is a stub. Switching the admin theme writes only the admintheme pref; it doesn't apply the new theme's defaults and deliberately leaves admincss alone with a standing //todo get the default from theme.xml (theme.php L462-L483, invoked from L444-L449). A switch can leave admincss pointing at a skin the new theme doesn't ship.

(The hardcoded bootstrap3 lock is the separate unblock in #5722; this issue assumes that's cleared.)

Recommended design

Mirror the frontend, reuse the substrate, keep it framework-agnostic so it doesn't wait on the BS5/tabler decision in #5723:

• Let a theme declare admin-scope settings the same way it declares frontend ones, stored in the theme_<name>_admin row via the existing $multi_row slot. No new pref table.
• Un-gate the settings tab for admin mode so a custom admin theme's config renders its own Preferences tab, and flesh out setAdminTheme() to mirror setTheme(): apply the theme's declared default admin CSS, seed glyphs, initialise the admin pref row. Closes the L469 todo and kills the dangling-admincss problem.
• Add thin admin-scoped helpers rather than changing the existing frontend signatures, for backwards compatibility.

And the bit you flagged, @Jimmi08: because the storage and the tab are generic, a CSS-variable framework like tabler.io drops in cleanly. An admin theme could declare its colour/layout knobs as prefs that the admin header emits as :root { --tblr-...: value }, so the look is tunable from admin preferences without touching templates. That's the payoff once the plumbing exists, and it stays framework-agnostic, so plain BS5 or tabler both benefit whichever way #5723 lands.

Decisions for @Deltik

Three forks where I'd value a steer before code:

1. How a theme ships its admin config. Either (a) reuse the single theme_config class and branch on scope, or (b) a dedicated admin_theme_config.php / class, mirroring how the admin face already lives in its own admin_theme.php. I lean (b) for clean separation.
2. Scope of v1. Ship just the mirror (un-gate the tab, admin pref storage, flesh out setAdminTheme) and treat the CSS-variable layer as a fast-follow, or build the CSS-variable layer into v1. I lean minimal-v1, same discipline we used splitting Allow custom admin themes (Bootstrap 5 path forward) #5686, so the prefs surface isn't held hostage to the framework choice.
3. adminstyle (infopanel/flexpanel). That dashboard-layout switch is core-include-driven today (admin.php L51-L92), not theme-owned. I'd leave it out of scope for v1 but flag it for later unification if a theme wants to own its dashboard layout too.

If that direction looks right, I'll write it up as the implementation plan on this issue.