Hi,
Following up on the issues I reported previously with the Popp theme, I took some time to dig deeper into the code to understand what was going on, both on the theme side and in IPS 5 core.
I was honestly surprised to discover that IPS 5 has completely removed parent-child theme inheritance. The `set_parent_id` column still exists in the database, but it's never referenced anywhere in the PHP codebase. So the idea of using a child theme to preserve customizations across updates, which seemed like the natural solution, simply isn't possible anymore (crazy...).
That said, I did manage to identify and fix the issue where the site was loading in light mode instead of the configured dark default for guests and private browsing sessions. The root cause turned out to be in the color scheme switcher script included in the "Scripts" custom template. When no cookie is set (first visit, incognito), the script defaults to `schemes[0]` which is `'light'`, effectively overriding the server-rendered dark scheme.
I've detailed both issues below with the exact root causes and suggested fixes, the color scheme bug which can be fixed on the theme side, and the css_variables overwrite on update which appears to be an IPS 5 core limitation but could potentially be mitigated at the theme packaging level.
Hope this helps!
Bug 1: Color scheme defaults to "light" for guests / private browsing
Environment: IPS Community 5.0.16, Popp theme, default scheme set to "dark"
Problem: When a visitor accesses the site without any cookies (private/incognito browsing, first visit), the page briefly loads in dark mode (correct, server-rendered `data-ips-scheme='dark'`) but is then immediately overridden to light mode by the Popp color scheme switcher script.
Cause: The custom template "Scripts" (hookpoint `core/front/global/globalTemplate:body`) contains the color scheme toggle logic. At the end of the `DOMContentLoaded` handler:
javascript
const savedScheme = ips.utils.cookie.get('acpthemedefault');
currentIndex = schemes.indexOf(savedScheme);
if (currentIndex === -1) currentIndex = 0;
applyColorScheme(schemes[currentIndex]);
When there is no cookie (new visitor, private browsing), `ips.utils.cookie.get('acpthemedefault')` returns `null`. `schemes.indexOf(null)` returns `-1`, so `currentIndex` falls back to `0`, which maps to `schemes[0]` = `'light'`. The script then calls `applyColorScheme('light')`, overriding the server-rendered dark scheme.
This happens regardless of the theme's `set__i-default-scheme` setting.
Suggested fix: When no cookie is found, the script should not override the server-rendered scheme.
Replace:
javascript
const savedScheme = ips.utils.cookie.get('acpthemedefault');
currentIndex = schemes.indexOf(savedScheme);
if (currentIndex === -1) currentIndex = 0;
applyColorScheme(schemes[currentIndex]);
With:
javascript
const savedScheme = ips.utils.cookie.get('acpthemedefault');
currentIndex = schemes.indexOf(savedScheme);
if (currentIndex === -1) {
/* No cookie found - keep the server-rendered default scheme */
return;
}
applyColorScheme(schemes[currentIndex]);
This way, if the user has never explicitly chosen a scheme, the theme's configured default (set via `set__i-default-scheme` in the theme editor) is respected.
---
Bug 2: Theme editor customizations lost on theme update (css_variables overwrite)
Environment: IPS Community 5.0.16, Popp theme
Problem: When importing a Popp theme update (XML), all theme editor customizations are lost: colors, slider configuration, layout settings, font choices, dark mode variables, etc.
Ccause: This appears to be an IPS 5 core issue rather than a Popp-specific bug. The IPS theme import code in `applications/core/modules/admin/customization/themes.php` (around line 514) simply overwrites the `set_css_variables` column with whatever is in the XML:
php
case 'css_variables':
$set->css_variables = $xml->readString();
break;
There is no merge logic, no comparison between the existing customizations and the imported defaults. The `saveHistorySnapshot()` call made before import only saves templates and CSS to `core_theme_content_history`, but does NOT include `css_variables`, `view_options`, or `theme_editor_data`.
The IPS default theme (set_id 0) stores its configurator values in the master CSS file (`1-2-settings.css`) as CSS custom properties (e.g., `--set__i-default-scheme: system`). These defaults are always present and the user's overrides in `set_css_variables` are merged on top at runtime (in `getCssVariables()`).
Themes Popp store ALL their configuration (slider, custom colors, layout, etc.) directly in `set_css_variables`. When the import replaces this column with the XML defaults, ALL customizations are lost, there's no fallback like the master CSS provides for the default theme.
Suggested improvements: Consider shipping the theme XML without `<css_variables>` content, or with only the theme's own default variables. This way, user customizations in `set_css_variables` would not be overwritten during updates.
My actual solution: We've created a backup/restore script that dumps and restores the `set_css_variables` and `set_theme_editor_data` columns before/after each theme update. This works but is fragile and requires manual intervention.
Thanks for reading and have a nice day
