AdminThemeUikit loads theme CSS from wrong module copy after switching module file

[matjazpotocnik]

When both core and site copies of AdminThemeUikit exist, switching the active module file can produce mixed asset paths.

Steps to reproduce

Copy AdminThemeUikit to /site/modules/.
Select the /site copy and load an admin page.
Switch to the /wire copy.
Inspect loaded stylesheets.

Actual result

/wire/modules/AdminTheme/AdminThemeUikit/uikit-pw/pw.min.css
/site/modules/AdminThemeUikit/themes/default/admin-custom.css
/site/modules/AdminThemeUikit/themes/default/admin.css

Expected result

All assets should load from the currently selected module copy.

getThemeInfo() stores theme paths and URLs in the session under themeInfos. Because both module copies share the same class name, switching files reuses paths cached for the previously active copy.

A possible fix is to store the module path with the cached theme information and rebuild the cache when $config->paths($this) changes:

 $session = $this->wire()->session;
+$config = $this->wire()->config;
+$thisPath = $config->paths($this);
 $themeInfos = $session->getFor($this, 'themeInfos');
+if($session->getFor($this, 'themeInfosPath') !== $thisPath) $themeInfos = [];

When rebuilding:

 $session->setFor($this, 'themeInfos', $themeInfos);
+$session->setFor($this, 'themeInfosPath', $thisPath);

[ryancramerdesign]

Thanks Matjaz, good find, and your diagnosis was correct.

Fixed in dev, though with a slightly different approach than suggested. Rather than tracking the module path so the cache can be invalidated when it changes, getThemeInfo() no longer caches derived values at all. The session cache now holds only the theme name and whatever its info.php provides, and the path and url are determined on return from the location of the module file actually in use. That removes the possibility of a stale path rather than detecting one case of it, and it means caches stored by earlier versions correct themselves rather than needing to be rebuilt.

Worth noting the problem went a bit further than the stylesheets you saw. The cached path is also used to include the theme init.php and ready.php files, so the active copy could end up executing PHP from the other copy. And since the existing cache clearing hook only removed the prnav and sidenav caches, a modules refresh would not clear this one either. The theme info cache is now cleared there too, which also covers info.php contents being cached by class name.

Verified by seeding the session cache with paths from a different module copy and confirming the correct paths are returned afterward.

-Claude