Have you ever been asked to create a website that uses completely dynamic content? Meaning, the same style of content doesn’t always appear in the same place the same way. There’s one big issue with using a standard Sitecore placeholder. There’s no way to have multiple renderings that happen to have the same Placeholder Key without it causing issues. If there are multiple places with the same Key, the datasource will be rendered in the first instance of the Placeholder Key.
I’ve ran into this situation with a few websites within the last couple years. The clients have wanted a dynamic way to build out a webpage rather than have the layout be dictated by the type of page. The time that this issue became really apparent was when the client asked for the ability to allow multiple “Multi Column” renderings to a page, but be able to vary where they went and vary what content went into them. I created a proof of concept for the client with the normal Sitecore Placeholders. However, once I tried to duplicate the content on the page with the a design file we had for demo purposes, I found out that there were some Placeholder Key collisions since I had multiple “Three Column” renderings. This pointed me in the direction of needing to implement Dynamic Placeholders. Dynamic Placeholders are not supported by Sitecore, but there have been a couple places where I’ve implemented other developers’ code and they seem to be working very well in both MVC and Web Forms. Of course, as with any solution, the logic to get the Dynamic Placeholders to work will vary depending on if you have a Web Forms solution or an MVC solution. So, click on either link for your solution.
What this solution does is take the Placeholder Key (eg. “onecolumncontent”) and append a GUID, usually the GUID of the current Rendering ID, to the end of the Key making it a unique key while not having to create multiple renderings with varying Placeholder Keys. As of my recent solution, there’s not a way to overwrite the display of the name in Experience Editor for the Web Forms solution, so you’ll end up with toolbars that look like the one I have pictured here. However, in the MVC solution, the GetDynamicPlaceholderChromeData() strips off the GUID and leaves the display name as your normal Placeholder Key. If you click into the Presentation Details of a page, you’ll see that these Dynamic Placeholders are also shown in here.
One big perk with using both of these solutions is that you don’t need to create new Placeholder Settings for each Dynamic Placeholder. The code will resolve to the correct Placeholder Setting by stripping off the GUID from the Keys. Now, in this screenshot, you’ll see that I have both MVC and Web Forms as solutions. The main reason for this is this client has both MVC and Web Forms in the solution depending on which site is being rendered. So, the main reasoning is for the Allowed Controls, not necessarily the Dynamic Placeholders.