Closed (fixed)
Project:
ThemeKey
Version:
6.x-3.x-dev
Component:
Code / API
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
13 Apr 2011 at 11:51 UTC
Updated:
11 May 2011 at 15:41 UTC
Jump to comment: Most recent file
When the themekey is enabled, and no rules match, themekey changes the global variable $custom_theme from the name of the default theme to the string 'default'. This breaks the Skinr module, since it's settings are saved for each theme, under the name of the theme.
The following patch ensures that the name of the $custom_theme does not change to 'default' when the default theme is the one that matches the rule. Instead, the actual name of the default theme is retained.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 11125920_d7.patch | 2.73 KB | mkalkbrenner |
| #4 | 1125920.patch | 1011 bytes | mkalkbrenner |
| #1 | 1125920-themekey-skiner-compatability.patch | 485 bytes | mrfelton |
Comments
Comment #1
mrfelton commentedComment #2
mrfelton commentedComment #3
mkalkbrennerthemekey_match_rules() is called by themekey_init():
So it's OK that themekey_match_rules() returns 'default'.
So if the global variable $custom_theme is set to 'default' in your setup, the bug must be caused somewhere else and your patch is not the correct solution.
Comment #4
mkalkbrennerAre you using ThemeKey UI?
I discovered the bug there.
Please, check if my patch solves your issue.
Comment #5
mkalkbrennerComment #6
mkalkbrennersame for 7.x
Comment #7
mkalkbrenner