Popp Theme

[Split]

19 godzin temu, ButterflyPixel napisał(a):

Come on ! It's not a problem of IPS. The normal template works perfectly, it's your template who is bugy... I already adverted you twice.

Fed up, changing template ASAP.

 

Since you claim you tested another template and it worked, I'll check it out and fix it as soon as possible. I care about my customers. Best regards.

[Split]

@ButterflyPixel Please update IPS to the latest version: 5.0.11 Beta 2. A patch has been added.

 

Cytat

#5361 Fix an issue where re-importing a theme can wipe the CSS table

 

Regards.

[ButterflyPixel]

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

[Split]

Spoiler

W dniu 10.03.2026 o 07:21, ButterflyPixel napisał(a):

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

 

 

Hi.

 

Regarding overriding CSS. As of version 5.0.15, it no longer overrides CSS from what I saw on my other site.

 

I know exactly which issue you're talking about. I reported it to the IC5 team and received the following information:

 

Cytat

We're aware of the issue there. However unfortunately there is no quick fix we are able to offer, and the solution may well be quite complex. As we dont know if the person has themselves created a template, we are not able to just go ahead and delete them in these cases.

 

After updating the theme, the template's "custom templates" become duplicated, causing a JS and CSS conflict. As the IC5 team wrote, they currently have no idea how to resolve this so that the content changes after the update.

 

Duplicate custom templates - Technical Problems - Invision Community

 

PS. Thank you for reviewing the errors and solving the JS issues. That's very kind of you.

Edytowane 12 Marca przez Split