Approach to Organizing Datasource Items in a Sitecore Multisite Solution
March 14, 2018
With any Sitecore project, it goes without saying that having a structured and organized Content Tree is key when it comes to managing data. Ideally, that data is organized in such a manner that reduces the need to duplicate content unnecessarily. Having many items with identical content not only leads to bloat within a project, but it also makes updating that content more difficult and tedious as each item needs to be individually edited. This post poses a solution for organizing the Content Tree that allows the ability for reusing datasource items across multiple sites in a Sitecore instance.
Datasource Items Associated with a Page Item
Logically, it makes sense that if a page item’s controls require the use of datasource items, those should be stored within a child folder underneath that page. This hierarchy groups all relevant datasource items associated with a page in one central location keeping the Content Tree organized. The following screenshot is an example of such a page with a child Content folder containing datasource items.
Also of importance is setting proper insert options to limit the potential for a Sitecore user to go rogue and begin creating items without this structure in mind. As is illustrated in the following screenshot in Content Editor, insert options for the Content folder should be limited to potential datasource items that may be used on the page.
It is important to note that while Content Editor is useful, insert options for the Content folder should be maintained on the Renderings as well to prevent improper items from being added. For users who feel more comfortable building out datasources in Content Editor, this technique limits the types of items that may be inserted.
Global Datasource Items
The solution above regarding page datasource items works well when each page for each site in a Sitecore instance has its own unique content, however it does not take into consideration the possibility that content may be shared across sites in a multisite instance. So how do we best address shared content and shared datasource items in such a situation?
The answer is to create a Global Content folder to house such items. Within that content folder, specific folders may then be created for each potential datasource type as is shown in the following example. Note that in this example, all Datasource folders are contained within an extra Content folder since the Global Content folder in this instance is also the location for other global content items (not shown) aside from datasource folders and items. This extra layer is strictly for organizational purposes and the concept remains unchanged.
Additionally, each Datasource Folder in Global Content now has insert options specific to the datasource template for that particular folder type as can be seen in the following screenshot.
With this specific Content Tree organizational structure, any rendering may then be updated to allow Content Managers to choose a datasource item in either a page’s content folder or from the global location. This is evident in the following Rendering where the Datasource Location field has been set to include the Content folder as well as the specific Global Content folder location.
Once the rendering Datasource Location is set, Content Managers are now able to select associated content from either the Content folder or the Global Content folder location.
Creating a page Content folder as well as a Global Content folder with proper insert options is a fairly straightforward process. Organizing content in this manner allows for specific page content to be created while also allowing for creation of global content. Global content may easily be applied as a datasource to renderings that span over multiple sites in a single instance limiting the potential for duplicate content and reducing the need to update content in multiple locations.
Stay up to date with our email updates!