With the embrace of local datasources and the luxury of general use components, a dilemma arises. These features cannot live on a Sitecore template's Standard Values item. Ideally a page template's presentation default lives on the template's Standard Values item. But if that default requires configuring a local datasource for a page component, then a branch template must be used. Or if the implementation provides a suite of general content components that an author can use page by page, there may be no specific default, but rather a general desired look and feel; a preferred combination of rendering parameters for certain components. All is well at first. A design path is chosen. Branch templates are created which beget hundreds, even thousands, of content pages. Inevitably a requirement comes along. Hey, let’s change that presentation a smidgeon... and terror sets in.
Recently I was involved in such a use case. We were using SXA and had imported hundreds of thousands of general content pages. Authors had tailored large quantities of these pages in Sitecore. Pages were rich with components: slideshows, jump navigation, rail navigation, banners, columns, related content, etc. All the SXA type components provide various styling options but were carefully set to match each sites original design. However, a time came and a decision was made. We needed to flip the columns so the right rail could be a left rail for all pages. And components needed to be updated with new variations, an SXA concept provided by rendering parameters, and have this new variation be selected in certain ways across all pages to provide the new look and feel. Just editing the Standard Values was not enough. We needed to process every page carefully to apply the new look.
Spoiler: the solution comes as a Sitecore Module. GitHub link provided at the end.
I dreaded the ghastly manual task, and plunged into the think tank swimming for a way to automate design changes in bulk. I needed a way to match certain conditions and apply certain actions. For example:
Conditions:
- If page is a General Page template
- And default device has a ColumnSplitter component
- And ColumnSplitter has two columns
- And first column is wide (grid 9) and second column is rail (grid 3)
Then, Act:
- Make first column rail (grid 3)
- Make second column wide (grid 9)
- Update placeholder paths of all nested components swapping columns appropriately
- Additional requirement, move components into wide column that are not in a column
Or more simply with SXA component properties, Act:
- Pull rail 9, push wide column 3 (via rendering parameters)
- Additional requirement, move components into wide column that are not in a column
This and other design rules could have all been hard-coded and hidden away; packed into a one-time-use, disposable script. But a light bulb flashed. Conditions. Actions. Rules. What if this could be done with Sitecore's rule editor? Then, anytime a bulk design change was needed a savvy user could whip up a new script using data items. No programming or code deployment needed!
Enter DesignBot, an automaton for the task.
With this Sitecore extension you have an area to define scripts. A script can be one or more rulesets, each having conditions and actions. The initial release adds 6 conditions to check presentation details, and 19 actions to manipulate rendering parameters, placeholder paths, renderings, datasources, and datasource field values.
I also found the need to use rule editor a bit differently than normal. It quickly became tedious and ugly to provide all the proper input to pick the desired rendering to alter. Often there were cases needing multiple actions to adjust the same rendering, which required redundant input for each action. Cases arose that needed groups of renderings to be affected. This led to the idea of making rendering selections first, then applying the actions to all renderings in this selection. So the script pattern became:
1. Guard - Use conditions to exclusively define items to be processed
2. Pick - Use actions to add renderings to Selection
3. Act - Make adjustments to all Selected renderings of item
4. Clear - Use “Pick - none, clear all selections” action to clear selection, so rule sets always start with no selection
5. … and repeat as needed.
The initial release of this module has 21 Pick actions for articulating selections.
Here is an example script definition:
Scripts can then be run on any item in the content tree and optionally traverse any range of descendants.
Here are a couple of our actual scripts for flavor:
This initial collection of rule extensions adapted to all of our immediate use cases is not, by any means, exhaustive. I imagine you may encounter needs which have not yet been covered. Extend this tool, adding actions and conditions as needed.
Here is the latest release and source code: https://github.com/digitalParkour/Community.Foundation.DesignBot/releases