If you’ve been following our BlogStream you’ve probably saw a previous post about some modularization work we did for a client so they could easily update color themes on their regional mini-sites. All of these regional sites live within the same content tree, utilize the same templates and page types, and point to the same physical files. In short any change we make applies to all of the sites.
So how do we give the client some control over that uniformity? Well you can read the Modularizing Site Themes blog post to see what we did for the CSS.
In this post we’d like to add a layer of complexity to that solution and give the client some options to control not only color themes but some higher-level functionality/template changes. Want to get rid of a link in the header? Sure. Need to allow for a deeper level of pages to be reachable on a listing page? No problem.
Normally when we are talking about Page Templates in Kentico we already start with quite a bit of flexibility. A creatively written Hierarchical Transformation can handle a number of scenarios depending on what the content tree looks like. What if the content tree looks the same across multiple pages but we want the information to render differently on different sites? Time for some settings.
The first thing we do is take the differences in the requirements and turn those into options that live on the Regional Site Master Page.
Well that was easy enough. Now we just have to make those switches do something!
Since these are all fields on the Master Page level we need to write some custom macros to access those properties. A macro method was already written to access the RegionalSite object properties so we can just extend that method to retrieve the field values we need. So we end up with macros that look like that return the value of that field.
How do we leverage this to our advantage? There are three primary spots where we will put this to work.
Kentico allows us to set visibility conditions for both Web Parts and Web Part Zones. Normally this is just a checkbox we can use to turn that element on and off. However, if you click on the triangle next to “Visible” it will bring up and editing box where you can set a write a more complex statement.
If your statement evaluates to “true” the web part/zone will be visible. If false, it will be invisible.
Now on the same template across multiple “sites” I can have this web part turned on or off depending on a Master Page level setting.
Page (Document) Types
On web parts like Repeaters and Hierarchical Viewers we need to specify what Page Types we care about looping through with our transformation. Normally this is a hard value but we can add a layer of logic to this as well. Click on the triangle to get your editing field and a quick ternary takes care of swapping the page types for us based on the Master Page level setting.
I get one set of page types when the setting is marked as “Yes” and a different set if not.
Defining what transformation a repeater or a Hierarchical Viewer is using is a single-selection operation, right? Not anymore.
This is where real power comes into play. I can completely rewrite my DOM output, what fields I’m using, and how deep I go (to name a few options) with a single switch. Couple this with your Page Type conditions and things just got a lot more flexible.
Once you realize this is a possibility you’ll notice that almost every field on your web parts and zones are editable in this way. Ostensibly we could wind up with two sites sharing exactly the same templates that look nothing alike. In most cases this level of granularity would probably be overkill. Here, we have Landing Page A and Landing Page B and the client can just select a new template for a given page if they need a different setup. When a high level of control over individual elements is required, however, having a bunch of different templates with names like “Landing Page A With Sidebar”, “Landing Page A Without Sidebar”, “Landing Page A With Sidebar Without Subcategories”, etc. quickly becomes a large burden for both developers and content editors and can cause a lot of confusion. This implementation provides the content editor a very simple and consolidated way to make decisions about exactly how the site will look and behave.
Have you ever run into a similar situation? Questions? Comments? Let us know below!