An ode to Sitecore Support and a different way to have multiple placeholders for tabs

This post is dedicated to Sitecore Support. Over the past 6 or 7 seven years of Sitecore development I’ve thrown dozens of loaded hot potatoes over to support to solve for me, and they have come through every time. So without sounding overly melodramatic, here’s to Sitecore Support – thanks for saving my hide – many times over.

And here’s the latest lifesaver.

A content feature that is often requested in Sitecore is a tabs module. A tabs module is a pretty common component of any website, and in Sitecore you can custom build a tabs module any way you want. A pretty basic one would be to allow the user to add tabs, and then add text underneath each tab via a text field. Using the page editor, we can make a nice easy-to-use tabs module.

A basic tabs sublayout, that allows the user to add multiple tabs and then add content/text underneath.

What would be really more flexible if we could instead swap out the text field with a placeholder and then allow the user to add whatever module they want – multiple modules, if need be. The only problem is that we don’t know how many tabs the user would add, so we would need to be able to add them dynamically. As most people that have been working with Sitecore knows, the layout engine of the page editor has some limitations with being able to render multiple placeholders with the same key. If you’re not aware of this, you can read all about it on Nick Wesselman’s Blog: http://bit.ly/1jUMo2P.

So a good way to do this would be just to use this prototype and then wrap it around a repeater – you can also use a regular placeholder, but then you have to assign the key value manually in the repeater. I’m using the regular placeholder, just to illustrate this example. Whether you use the regular placeholder or the dynamic one, you have to add the GetDynamicKeyAllowedRenderings to the getPlaceholderRenderings pipeline, so you can get the correct allowed renderings for the placeholder:

protected void rptrTimelineItemsEdit_OnItemDataBound(object sender, RepeaterItemEventArgs e)
{
    if (e.Item.ItemType == ListItemType.Item || e.Item.ItemType == ListItemType.AlternatingItem)
    {
        Item item = (Item)e.Item.DataItem; 

        Placeholder scPlaceHolder = (Placeholder)e.Item.FindControl("scPlc");
        scPlaceHolder.Key = "itemcontent" + item.ID.ToString().ToLower(); 

    }
} 

If you don’t use the page editor, this works great. However, if you use the page editor, you end up getting an error when adding any other sublayouts:

Could not find the rendering in the HTML loaded from server PlaceholderChromeType.js:601
Sitecore.PageModes.ChromeTypes.Placeholder.Sitecore.PageModes.ChromeTypes.ChromeType.extend._frameLoaded


It pointed me the file, but I wasn’t entirely sure what the issue was. When I put the placeholder outside of a repeater, it worked fine. So I contacted Sitecore Support. They told me that the issue only occurs when a repeater is placed on a sublayout that is inserted into a placeholder. If the Repeater is added to a layout directly than everything works fine. So then problem exists when placeholder from the repeater is nested in another placeholder. They provided me with a replacement of the PlaceholderChromeType.js file that goes to replace the existing one in:

\Website\sitecore\shell\Applications\Page Modes\ChromeTypes\PlaceholderChromeType.js

Also, you have to make sure that any placeholders created this way must have the keyword ‘dynamic’ in it, and all static placeholders must have names that do not contain “dynamic” substring, as they will be processed as dynamical.

The updated .js file can be found here: https://drive.google.com/file/d/0B1J6kaxsX5DoMERXc2JWaUlCMDQ/edit?usp=sharing

Once done, the placeholders render beautifully:

The multiple placeholders appear correctly and and show the correct renderings when clicked.

This is obviously not limited to a tabs structure, but can be used in multiple places to allow dynamic content, such as slideshows, timeline controls, etc.

Note: This indeed has been reported as a bug, and is not currently in the queue for release, as far as I’m told. This was tested and working great in version 6.6 rev 120918