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.




7 thoughts on “Keeping Your Sitecore Tree Organized

Add yours

  1. I’ve found it quite rare for content authors to create Datasource items from the Content Editor. Instead most will create them through the Experience Editor when adding a rendering. Whilst you can generalise and let authors create those datasourced items in whatever hierarchy they choose, it’s not possible to do from the Experience Editor alone. Instead, we have set Datasource Template and Datasource Location settings on Renderings to force a certain pattern. This keeps it consistent throughout the project, with all authors working the same manner and working with the business early on to establish what would work best means the solution delivers something that works well for everyone.

    1. I can understand that solution. However, we have clients that are used to creating datasource items in the Content Editor then just referencing them in the Experience Editor. The way you have outlined will work as a general rule. However, this way also does prevent some understandings of expanding to a multi-site solution. Sure, you’ll be able to do it. But, for each site you add, the number of datasource items will increase exponentially. This means, either you’ll have to expand the functionality of how everything is organized by adding additional folders, or, you’ll have to add the components into an item bucket if it gets to be that many.

      We have done the way you’ve outlined in other projects we’ve worked on. However, in my experience, that is best utilized for a smaller, single site project.

      1. What’s the difference between organizing this in a single site or a multisite solution? I would imagine a better way of organization is by type, i.e. a Call to Action Folder template whose insert options has a Call to Action template. This would make your datasource locations for your renderings make more sense as well.

      2. As a general rule, the organization shouldn’t be much different. And, depending on your naming scheme, this solution would work as well. So, if you had a Call to Action item called “Site A – Contact Us” and “Site B – Contact Us”, then you could easily figure it out. However, if you just have 2 items called “Contact Us”, then a content author could be confused as to which site this item is for. However, if you set it up to be “Site A/Contact Us” and “Site B/Contact Us”, this would also make logical sense. But, with the ever expanding number of sites for clients, we wanted to allow the client to be able to organize their solution to what they wanted and give them the ability to expand their organization as well.

      3. I don’t agree on scale. A site which has been designed and set up well can be entirely managed from the Experience Editor, and when you’re working at scale on larger projects with larger number of editors it more important to make things easy to use – and driving that from a WYSIWYG experience.

        I’ve worked on numerous multi-site projects. The way we’ve dealth with this: Global Content, Site Shared Content and Local Content folders. Within each of these folder, you can further organise the datasources by type into additional folder, using code to auto create these folders by looking up the structure from Datasource Locations fields by tapping into the getRenderingDatasource pipeline.

      4. I would argue that the Site A Contact Us item should be under the Site A site node instead of somewhere separate. I wouldn’t want a content admin from Site B accidentally adding something intended for Site A and vice versa.

      5. I would also argue, that by lumping everything under a single folder, you’ve broken multi-tenancy rules and can longer set permissions on a site by site basis.

Leave a Reply

Powered by

Up ↑

%d bloggers like this: