In today's post, I'm going to talk about Sitecore Items. A Sitecore 'item' is the basic building block for everything that makes up a Sitecore website. When you build a website using Sitecore, it will be powered by .NET. When we talk about Sitecore items, forget about C# and HTML files for now, as Sitecore items have no relation to code files, .NET concepts of files on a filesystem. A Sitecore 'item' is a virtual object that lives within Sitecore itself (the database).
When you open up the Sitecore Editor, you will see a navigation tree. Every entity within this navigation tree is known as an item. The first item in the tree is called the 'Sitecore root item'. Everything else that makes up your Sitecore website lives underneath it. This hierarchy is the quintessential example of a parent/child relationship 👪.
Each item can only have one parent, while any item can have multiple children. Underneath the main Sitecore item, by default you have access to the following items, 'content', 'media', 'layout', 'system', and templates (the use of each of these will be explained in the next tutorial). Each one of these items will play a critical role in Sitecore CMS development.
To help developers understand how 'items' fit into the mix, most material on Sitecore compares 'items' to 'objects' in object-oriented concepts. Like an OO object, items can be used to represent different things. Some items will represent content, some items will represent templates, some items may even represent settings, like an option for a drop-down list or an image. Items can even inherit from other items to prevent duplication, so one item might be constructed of 2 or 3 different items.
How Sitecore deals with items, is quite different compared to a lot of other CMS systems. Most other CMS systems, like Episerver for example, only allow content pages to be created within the main page hierarchy. Having your whole system based on an only content model has its pro's and cons. The pro's of a content only structure is simplicity. It's definitely easier for content editors and developers to understand the solution. In a content only tree structure, each item represents a page. The order of the tree, represents how the website will display, simple. Things get a little bit more interesting when you want to store data. If, for example, you need to render a custom drop-down list on a page. The drop-down needs to display values that are configurable in the CMS, where do you put this data?
In Episerver, you may need to create two new page templates called 'Dropdowns' and 'DropdownValues' which will live in the content tree. Technically, these values aren't web pages, so you end up with a structure that can be quite messy. If you are a bit of an OCD freak and you think in purist terms, you might not like the idea of having these settings within the 'content' tree. As the pages represent meta-data rather than page content. In Sitecore, you do not have this problem. You could add the data using out-of-the-box 'Setting' data templates.
As Sitecore is more than just content, the same item wouldn't live in the 'content' section in the navigation tree. In Sitecore, the item can live within a more relevant area that makes more sense like 'Layout'. If you're reading this and thinking brilliant, 'why doesn't everyone do it like this?' then I'll try to explain why this approach isn't always ideal in every situation.
If you have a simple project where you only want items to represent pages and nothing else, this concept of items creates a complex tree. Sitecore is a lot harder to master compared to a lot of other CMS systems. In Sitecore, it can be confusing and hard to find what you want, quickly. The Sitecore tree is big and complex and finding items in the Sitecore tree can be frustrating at times. A good challenge to prove this is to try to update the WFFM (forms add-ons) email setting without having to Google it. This added complexity is a common trade-off with Sitecore, as well as a great example of how different CMS systems are suited to different companies. If you want a simple CMS interface, Sitecore may not be for you.
In general, with an objective and item approach, you may need to create more 'items' and perform more clicks compared to other CMS systems. The trade-off with items is flexibility, you can create more objects and represent more data with less effort. Happy Coding 🤘
