Note: This tutorial uses some ThemeKey properties from an additional module called ThemeKey Properties.
In this tutorial you'll learn how to define ThemeKey rules and how to cascade them to achieve sophisticated rule chains.
The use case is to use a different theme during content creation for premium users, e.g., you don't want to show advertisements or you want to show some advanced help blocks ...
Therefore you created two user roles called "premium user" and "standard user". Using ThemeKey it's easy to create a rule that switches the theme if a user's role is "premium user":
Similarly, we can also create a rule that switches the theme if a content creation form is requested. To do this for any kind of content we use ThemeKey's drupal:path property and its wildcard feature:
But having these two separate rules is not what our use case describes. To implement our use case, we have to cascade or "chain" both rules. By dragging on the cross icon in front of a rule, you can move any rule up and down or indent it. The chain we need should like this:
Now using this chain, ThemeKey only switches the theme on content creation forms if the current user's role is "premium user". Non-premium users will use the current standard system theme.
You might have noticed that the theme select box disappeared for the first rule as you indented the second one. That's because both separate rules became one.
Now it's possible to extend our chain to use another dedicated theme on content creation forms for "standard users".
If you have more than these two roles in your system and you simply want to use one theme for premium users and another for non-premium users, on content creation pages, you don't need to add one rule per role, as described above. In this case, it's easier to change the latest rule we added and say any other rule other than "premium user", using ThemeKey's not operator "!".
Now that we have implemented our use case using chained ThemeKey rules, you can add more rules to ThemeKey's Rule Chain to implement different use cases. The only decision you have to make is the order the rules are checked by ThemeKey on every page request. To demonstrate this, let's add another rule that switches the theme if the user uses an iPhone to access your page.
What happens now is that ThemeKey switches to a special theme for iPhones whenever the user accesses your page using such a device, because ThemeKey stops processing the rules if a rule, or one set of chained rules, matches. This means that content creation forms are shown using the iPhone theme, regardless of the role assigned to the current user.
I think that's a good choice. If you move the iPhone rule below the chain for the content cration form, these forms will use the configured themes even on the iPhone, which might not be suitable for displaying them.
If you'd like to treat node creation forms differently, even on the iPhone, you should "chain" a dedicated set of rules for that.