Ever need to personalize Sitecore rendering parameters?
Sitecore's conditional renderings allow you to override the datasource and/or the component. However we often run into the need to override rendering parameters too. It may be the desire to simply change a color that is specified as a component property. Or it may be something more critical like what I ran into last week with Sitecore Experience Accelerator (SXA). SXA has a mechanism called rendering variants. This is very cool for reusable components, such as Page Content. An additional property can be set to choose the display variant as appropriate, such as News Variant, Event Variant, Contact Variant, etc. This also works well for a general Promo component too, offering choices for different display variations. That's where we hit a wall. We wanted to personalize a banner. Case A used one variant, Case B used another. However this choice of variant is stored as a rendering parameter, which is not managed out of the box with Sitecore's conditional rendering engine. This means each conditional case will get the rendering parameters of the original component. Furthermore making a Case C to use a different component, say a rich text component would be even worse, as nothing would render for us. This is because with SXA 1.4 the rich text (reusable) component also supports rendering variants. However, it was getting the value of the Promo rendering variant passed to it, which was incompatible (wrong field names), and thus nothing rendered.
For these reasons and more we really needed a way to manage the rendering parameters with our conditional rendering personalization cases. Fortunately extending the CMS is where Sitecore shines! And this one was no exception; it only took a few slight modifications to enable parameter personalization. In fact there was already a rule to set the parameters (as a query string). It just wasn't visible. Spoiler alert, source code is available at the end.
Step 1:
First we needed to get the action options to show in the personalization dialog. They are hidden by default.
At first I thought this was all I needed to do, since there was already a rule action to set parameters, but this action was not getting applied.
Step 2:
Apply the parameter rule for personalization.
I was only concerned for MVC renderings, and it was pretty easy to find the pipelines responsible. It just needed a line to transfer the rule result rendering parameters to the context rendering parameters. I did have a little trouble pinning down where Sitecore applied the rules when toggling between display cases in Experience Editor. Sitecore Support was swift to point out the area responsible. Thank you Sitecore Support!
However after testing we quickly found the rule was quite inadequate. Among other issues it was too tedious to list all parameters to only modify one. So I added three new conditions to handle basic use cases.
* set [parameter] to [value]
* set multilist [parameter], append [term]
* set multilist [parameter], remove [term] (if exists)
Still, these require the user to know the name and value of the parameters. So I’d recommend tailoring the UI of these rules and eliminate this knowledge requirement. For example, you could use a dropdown list with preconfigured options instead of the default raw text input.
Grab the Sitecore package from the marketplace, or get the source code.
Happy coding!
About Author
