In the Configuration > Design > Themes. There is new feature since v1.1. But I really can’t figure how it works, and what it does even the name spelled clearly ‘giving exception to the theme’.
And I am totally clueless to this:
Match expresions in the same order as displayed in the configuration.
I’ve been wondering this myself.
I tried putting a file name in the exception and my theme name for the value. That didn’t work. But what other possibilities did you think of?
I haven’t tried taking the time to trace the code to see what they are comparing and what they do with it if it matches. All that stuff seems to be buried deep and it’s hard to follow.
design exceptions allow store owners to specify alternative theme for a specific user agent. A greater example of this is of our iPhone optimizer. Using design exceptions you are able to specify that anyone visiting from the iPhone that will see this store view.
Varien: Please let us know how ADD EXCEPTION works. Thanks.
I have many stores that look nearly identical, though would like to have a heirarchy of changes:
Store 1
Store 2 looks like Store 1 with some differences
Store 3 looks like Store 2 with some differences
Store 4 looks like Store 3 with some differences
. . .
as joyously pointed out—and thanks for that!—, it’s “only” to match against the User-Agent ~ Browser ~ ‘HTTP_USER_AGENT’
The functionality is coded in “\app\code\core\Mage\Core\Model\Design\Package.php”, function _checkUserAgentAgainstRegexps()
Each exception must be written is a regular expression and if it matches the given interface/package, theme, locale, etc. is used. If a “Mobile Browser” like ‘iPhone’ or some PDA comes around a different layout and theme is automatically enabled w/o that visitor’s intervention. You may thus also apply a different “optimized skin” whether it’s a Gecko, Explorer, Webkit, AvantGo, Nokia ... engine.. or a search engine, maybe?
> Match expresions in the same order as displayed in the configuration.
this basically means that the regular expressions are applied in “order of appearance” and the first match (per group) wins.
> though would like to have a heirarchy of changes:
I believe this is controlled using the “Default” (Standard) value which is the last one in this set of settings. I’m NOT entirely sure (didn’t try it), but it appers to be a “theme name” that’s used as the fallback, if the “active” theme has no matching resource ... however always looking at the “default” theme at last.
So your overrides should look similar to this, using the “reverse” order of dependecy:
Store 4: theme = “store4”, fallback: “store3”
Store 3: theme = “store3”, fallback: “store2”
Store 2: theme = “store2”, fallback: “store1”
Store 1: theme = “store1”, fallback: “modern” (or empty for “default")
> though would like to have a heirarchy of changes:
I believe this is controlled using the “Default” (Standard) value which is the last one in this set of settings. I’m NOT entirely sure (didn’t try it), but it appers to be a “theme name” that’s used as the fallback, if the “active” theme has no matching resource ... however always looking at the “default” theme at last.
So your overrides should look similar to this, using the “reverse” order of dependecy:
Store 4: theme = “store4”, fallback: “store3”
Store 3: theme = “store3”, fallback: “store2”
Store 2: theme = “store2”, fallback: “store1”
Store 1: theme = “store1”, fallback: “modern” (or empty for “default")
I don’t think this would work. Since it only references themes/skins the fallback value “store2” would only reference the change made for “store2” and not fallback to a tertiary “store1”.
ahh… got it. My bad. I think you are correct
However, you may as well get away with symlinks or handlinks to the files (or folders) to keep changes synced. On Windows + NTFS you can use junctions.
Just a though.