What is Sitecore CMS? Sitecore is a company founded in 2001 that develops and licenses a Content Management System (CMS), also called Sitecore.
The Sitecore Content Management System allows marketers and content authors to add and update web site content without the need to involve developers. A CMS seperates the content of a web site from the visual design, and removing the need for developer involvement allows marketers to make quick content changes many times a day.
I have been working with Sitecore for 10 years now and have seen it evolve from version 6.5 to the current version 9.3. Sitecore has invested heavily in the marketing features of the platform over this time, but the content management fundamentals have remained largely un changed.
The following infographic summarizes the key concepts used by the Sitecore CMS to manage content and render that content on a page
The Sitecore CMS is built on ASP.net and supports Web Forms as well as Model View Controller (MVC) with Razor. Sitecore has recently added Headless support with Sitecore JSS.
Unlike Wordpress, Sitecore does not ship with themes and cannot be used 'out of the box' to create a web site. Development work is required to add site theming and custom support based on page design. Sitecore Experience Accelerator is a module that can speed up this process by allowing content definition and authoring to happen while design and styling is added in parallel. But this simply speeds up the development process.
Everything in Sitecore is an item. Items are the architectural foundation of the system. Items are instances of templates. Template define the field 'schemas' of items. A Blog post like this one has its field structure defined in a template, and each post is an instance of that template, an instance 'item'. It is easy to confuse templates with page design artifacts and I find it unfortunate that the term template is used by Sitecore. Umbraco calls these things 'Content Types', which I think is more intuitive.
Typically development starts with the creation of a template. For example, if you need a banner on a web page, you might create a template for the page with the fields for the content that the banner displays. An image field, banner title, subtitle and maybe a CTA button link field.
Templates are also items, which is a bit of a meta rabbit hole. So let's leave it at that.
Layouts represent page containers. These are ASP.net MVC Layouts or ASP.net master pages if you are using webforms.
The Sitecore content tree defines the site URL structure. Items represent pages and requests for items via URL paths trigger a process known as the Sitecore processing pipeline. The layout associated with the template that the item is based on is loaded with the current item set as the data context.
The following code is an example of how data is retrieved from Sitecore using the current context item.
var bannerTitle = Sitecore.Context.Item.Fields["Banner Title"].value;
Renderings and Sublayouts are components that are rendered into layouts. Sitecore leverages ASP.net placeholders to position components. This gives authors control over where page elements are placed. It is also possible to nest components, so a component could consist of multiple sub-components. I would recommend keeping things as simple as possible however, it is difficult to test the possible combinations of scenarios that come with this complexity, and HTML renders based on content flow where elements affect each other making this approach fragile.
Renderings are the components used in MVC solutions and SubLayouts are used in WebForms. It is possible to create a hybrid site that uses both MVC and WebForms, but I recommend sticking with one approach, MVC is the modern strategy.
Renderings and Sublayouts can be applied to placeholders defined in a Layout. It is possible to control which placeholders can accept components. If multiple components are added to a single placeholder, they will be stacked.
Sitecore uses SQL Server. Support for Oracle has been discontinued. For some time Mongo DB was used to support the Marketing site visit data, but this has been replaced by SQL Server with sharding.
I believe dropping Mongo was a good move, even though I am a fan of MongoDB and agree that it was the right tool for the job, keeping the technology stack simple was a good architectural decision
The Sitecore 'Core' database is the foundational datastore and contains template defintions to support the content feature and Sitecore UI elements. The Core database also stores the use accounts and roles.
All site content is stored in the Master Database. The Master database is where in progress authoring occurs and forms the content 'system of record' for the site. Content can be moved between Sitecore instances using 'Content Packages' which serialize content. I have successfully moved content from version 6.5 to version 9 using Sitecore packages. This is a good strategy for content migrations after upgrades.
The Master Database is where CMS development and authoring occurs. Templates are defined in this database as well as Renderings, Sublayouts and layouts
The Sitecore CMS Web Database is similar to the Master database, however it only stores the 'published' content that is currently served by the live site.
This sums up the basic structure of Sitecore and describes the mental model that a developer needs to be familiar with to work with Sitecore.
I have only scratched the surface of the rich functionality that Sitecore offers.
Looking for more Sitecore? Read my post on Must Have Sitecore Modules
Photo by Joel Filipe on Unsplash