Keeping Your Sitecore Tree Organized

There’s one big thing that should be on everyone’s mind when working with a lot of content.  That big thing is organization of the Sitecore content tree.  With a single site solution, organization can be a little less serious.  But, once you start to deal with a multi-site solution, organization is key.  There are so many different ways for a content tree to go from being very cleanly organized to being one of the most confusing things to try and navigate.  Admittedly, I like my content tree like how I have my folders on my computer, very organized.  That way, when you need to find something quickly, it is very easy.  If it’s disorganized, then it ends up being a longer process to find the item.  Which, multiplied by however many components you have on a page, could really affect how quickly you can create a site.  So, when I see a Sitecore tree that seems to have items spread out all over the place, I want nothing more than to help the client clean it up and give them the tools to keep it clean.

Component Tree 1

Let’s take a look at this screenshot.  In this multi-site solution, we have created components (or modules) to be added separately to the page allowing the content editor to essentially be able to build out a webpage from a blank slate.  So, due to the number of components that will be created, it is important to keep the components folder organized in order to quickly find the datasource you’re looking for.  As a developer, when setting up a components folder, one of the easiest, but more restrictive, ways is to create folders yourself and only allow the content editor to insert that type of component in that folder (eg. Creating a Rich Text folder and only allow a Rich Text component to be inserted below it).  This isn’t the way I wanted to implement this organization strategy since I didn’t exactly know if the client wanted them to be organized by site, by component type, by both, etc.  This way also doesn’t easily lend itself to growth since it’s more restrictive for the content editor.  So, a more flexible way to implement this is to create a new folder template and give all your components as an insert option to this folder.  But, the key step here is to also add the same folder template as an insert option as well.  This will allow the content editor to make folders as they please and organize the Sitecore tree to how it’ll make sense to them.

Component Folder Insert Options

Now, these were all ways as a developer to help the content editor.  But, a content editor should utilize these tools that the developer has implemented.  If a developer hasn’t implemented a good way to organize the Sitecore tree, it is absolutely worth asking.  This will only help out with confusion in similarly named components, identically named components that are different templates, etc (as mentioned in Keeping Item and Field Names Unique).  As a content editor, it is also worth thinking about how you want your data structured in Sitecore before you start building out your content.  This way, you could build out your folder structure logically before adding any sort of content.  If you don’t want the ability to create folders of your own, but want the restriction of only being able to add a specific component(s) under a certain folder, work with your developer and implement it together.  This way, you’ll have a way to organize your data that you’ll be happy with.  Personally, I’m a fan of giving the content editor the ability to structure their data as they please.  This allows the solution to easily expand if additional sites are added.  This also gives the ability for the content editor to change their mind about how the tree is structured.  Let’s say the content editor just wanted all the components to be grouped together regardless of site.  Well, after the content editor starts to get hundreds of components, that organization process may not be sustainable anymore.  Instead of needing to go to the developer and paying to have an additional ability to change how the content tree is organized, that ability is already there and the content author can alter that item structure without any negative effects to the site.

Component Tree 2

In the end, as a developer, the most important thing is to deliver a solution that the client is happy with.  Knowing full well that there will be some complex data that will need to be made easier for a content editor to work with, organization is key.  As you can see in the “Component Tree 2” screenshot, I have organized the components from the “Component Tree 1” screenshot into easier to understand folders by using the same insert options as shown in the “Component Folder Insert Options” screenshot.  If there are even more components, and there still are too many items under each folder, you can easily add another level of the site that they’re created for.  But, for this situation, just doing the one level is enough.  It is all dependent on how much content is going to be going into each site and how easily it is to understand where to find those items.





Keeping Item and Field Names Unique

There are many things that can help with confusion as a developer and as a content author.  One of the biggest confusions I’ve come across has been duplicate item names, fields, and placeholders.  Sitecore will render whatever the first instance of that name is.  So, if you have an item with the same name as another, it will render the one higher up in the tree.  The same idea expands to placeholders and field names as well.  There’s a way to work with the placeholders and not be required to create multiple placeholders that have the same function called “Dynamic Placeholders“. However, the other two require some discipline as a developer and a content author.

As a content author, to avoid general confusion, giving unique names to items will avoid a possible situation where content you’ve entered is not showing up properly or not at all.  I’ve run into a few situations where the client has asked me to troubleshoot why the content they’ve updated was not displaying like they were expecting.  When I started troubleshooting, I noticed that there were items that had the same name.  It turned out they were editing the lower of the items which meant the rendered content wasn’t actually updating.  In addition, I had also noticed that other renderings were missing content entirely.  After looking into this situation, I found out that there were different templates that were utilizing the same name as well.  So, the content author added a Rich Text block to the page and correctly pointed the Datasource.  However, the item above it was an Accordion template that shared the same name.  Since Sitecore uses the path to get to the Datasource as opposed to a GUID, the rendered page was trying to render the Accordion template in the Rich Text rendering, which didn’t render properly.  One of the easiest ways to do this is to either put all items that belong together in a folder or name each one differently but name them in a way that a content author will understand that they go together (see green highlighted area).

As a developer, however, one of the things that will avoid general confusion for content authors is to name your template fields well.  Naming something “Content” can work if you’re creating a template that’s going to be inherited in to multiple places.  However, if you are creating a field specifically for a template type, it’s worth naming your fields more specifically.  As you see in the screenshot, there are two fields named “Page Title”.  One field is being inherited while the other field was added to the template itself with the same name.  This means, the first one will be the field that gets rendered while the second one is about as useless as it can be.  To avoid these types of situations, it’s good to plan out your templates before you create them to see what fields are being inherited and what fields you’ll need to create.

Page Template vs. Component Site Architecture

In the last couple projects that I’ve worked on, I’ve been faced with a very common question.  How should we architect the solution, using Components or Page Templates?  Components meaning a piece of data that can be used in multiple places and can be rendered anywhere on the page.  Essentially a free way of designing a web page without needing a developer’s intervention.  Page Templates meaning a much more rigid design of the pages that will prevent possible design complications.  There are major pros and cons to both of these options, and most people will end up wanting a combination of the two.

Page Template Architecture

pagetemplatepresentationdetailsThis is one of the more common ways to architect the Sitecore content tree.  Essentially, you create numerous page types depending on what data you want to display on the page.  For example, you’d have a Homepage, a Products page, a Product Detail page, a 404 page, etc.  The perk of the Page Template architecture is that all the fields that are on the Page Template are relevant to the page and only that page.  There should not be any fields that crossover between the different pages that aren’t relevant to that page, assuming you inherited properly.  This also allows for all your data to be entered in one place.  All you’d need to do is create the page in the content tree and enter all your data in that item.  However, a perk and downfall is that a content author does not have control of the look of the page.  That is controlled by the template and layouts associated with that template.  The only choice the content author has is which template to create.

However, there are few downfalls to this architecture.  If you wanted to allow for any additional data to be added to the page, it would require some developer intervention to not only add the field in Sitecore, but to add the ability for the code to render that data.  This architecture also doesn’t make any repeated data easy to content manage.  Each time you created a page, you’d need to re-enter any repeated data.  Unless, of course, it is set in the Standard Values of that template.

Component Based Architecture

componentspresentationdetailsThe biggest perk to having a Component based architecture is the flexibility it provides the content editor.  You can take a blank page, and with the power of a handful of components, you can build a webpage multiple different ways.  Do you want a page that has 2 columns at the top with 1 column below that with a YouTube video in the 1 column and a rich text component in the left column and an image in the right column the 2 column one?  How about on the next page, you want that layout to change up a bit.  You can put 1 column at the top of the page with an image in that while the 2 column can go below it with a YouTube video in the left column and the rich text in the right.  Having a component based architecture allows for that.  It also allows for one page type to be created.  This is also depending on if all pages will have the same basic structure and data.  There may be some exceptions to this if there’s additional data that needs to be added specifically for certain page types.  The content author would create a page in the Sitecore content tree, then would start building out that page in the Experience Editor.  In the Experience Editor, there will be one placeholder that would allow for the structure of content (eg. one column, two column, three column, etc.).  Within that content, there will be additional placeholders that would allow for all the different component types to be inserted into them (eg. image, rich text, YouTube video).

There are also some very noticeable disadvantages for this architecture.  One of the biggest ones is that the content you enter is separate from the page itself.  So, you’ll need to not only create the page, but you’ll need to create the datasource as well.  Another disadvantage is the default Sitecore Placeholders don’t take into account adding multiple of the same placeholder (eg. adding two 2 column renderings that have “leftcolumn” and “rightcolumn” placeholders).  This can be solved by the use of Dynamic Placeholders.  However, Dynamic Placeholders aren’t an out-of-the-box solution from Sitecore.  So, there will need to be some custom work added to enable that ability.


hybridpresentationdetailsWhat a lot of people settle on is a hybrid of the two of these architectures.  For example, you have a News Feed page.  This page pulls in a feed of any articles you have published.  The layout of that page shouldn’t change.  However, there can be placeholders placed at the top or bottom of the page to allow for flexible content to be added.  There are even more options that aren’t as obvious.  It could be as subtle as the HTML structure being slightly different between two fully component based pages.  For example, one renders slightly wider than the other.  This would require a different sublayout or rendering which would mean that a developer would need to create a new template in order to add that wider sublayout or rendering to the Standard Values as opposed to the narrower initial sublayout or rendering.

Dynamic Placeholders

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.

dynamicplaceholderkeyWhat 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.