What is Sitecore?
The question, 'What is Sitecore', leaves me wondering how I can create a concise, yet informative answer because Sitecore is more than just a CMS. It is a Website Development Platform, a Web Marketing Platform, a Web Page Designer, and a Content Search Tool with an active Development Community.
Sitecore is an enterprise content management system (CMS) developed by Sitecore corporation. Based on ASP.net, Sitecore was introduced in 2001 and in late 2019 released version 9.3. The Sitecore CMS provides a platform with which developers can create custom website page components. Non-technical content authors can manipulate these components to create and update website pages. Digital Marketers can manage content specific to visitor audiences and manage email campaigns.
Sitecore is used to manage a site’s content tree, the hierarchical structure of a website’s information architecture. Sitecore content is described in templates. Think of Templates as ‘content type’ definitions comprised of collections of named fields and field types. Template are used to create items, which is where content is stored (in the fields defined by the template).
Sitecore also provides a digital marketing platform that captures site visitor analytics, A/B testing, email campaign management, and user audience based content personalization. See: Tracking and Personalization. The marketing automation platform can also be extended with custom development.
Sitecore is a Platform
I have been working with Sitecore for 9 years since version 6.5, and from a developer perspective I can truly say that Sitecore is a platform to be built upon. Sitecore does not ship with default content types or components and themes like WordPress.
Sitecore cannot be used ‘out-of-the-box’ to create a site.
It is a blank canvas ready for custom back end and front end development. While Sitecore doesn’t include much front-end presentation functionality, it does include a rich back-end.
Templates and Items
Templates are a cause for developers new to Sitecore. In general web lingo, a template is a page layout, a design that is ready for content. However, in Sitecore, a template is a content type. A template is a set of fields that describe a data schema for content items. For example, a template could be used to define the content fields that appear on a page, such as a home page or product page. To create a page, an author creates an item based on a developer defined template in the content tree and adds content to that item.
Layouts, Renderings and Sublayouts
Layouts represent page structures, and renderings and sublayouts are visual page components that make up a page. A layout is a master page that renders the html that is common to all pages on a site. Renderings and sublayouts are reusable sections of html that are rendered into placeholders in a layout. Sitecore items are associated with a layout and renderings or sublayouts. A layout is rendered in the context of the current item and pulls the fields from that item into the html defined in the layout components as coded in either MVC controllers or WebForms ‘code behind’ depending the ASP.net implementation architecture.
Sitecore originally shipped with ASP.net webforms support, and it still supports this architecture today. A WebForms implementation defines its component model using user controls (ascx files). These components are called SubLayouts, and they are rendered within a layout into placeholders defined in the layout. Sitecore WebForms includes a collection of ASP.net Server Controls with the ‘sc’ prefix that can be used to quickly render fields from the current context item (the item associated with the current page in the site tree).
ASP.net MVC support was added to Sitecore version 6.6, and support for MVC has grown such that it is now the preferred and recommended architecture. Renderings are the Sitecore MVC components instead of SubLayouts. Renderings render html within layout page placeholders and can be placed on pages very much like sub-layouts can.
The 2 main types of rendering are View Renderings and Controller Renderings.
View Renderings are for simple components that have no back end logic, they just move field data from items to views. Controller renderings include a controller that can provide additional processing logic. I tend to use controller renderings, even if there is no logic, but to have a place where logic can be easily added if necessary.
The Sitecore media library is used to manage site assets like images and pdf documents. Media is served through ASP.net handlers which abstracts out the folder structure so media items can be moved easily without breaking links. Standard image file types (eg.png, jpg) are supported by default, vector graphics can also be used with a configuration change.
Experience Editor (once known as page editor), allows authors to edit content in a wysiwyg style. This is similar to the WordPress authoring experience. Developers can expose component placeholders in layouts that authors can use to place components and build pages.
Components on a page will attempt to find their content from their context item. However, components expose a property called ‘data source’ that can be used as an override to the context item. This data source property creates powerful content sharing opportunities. For example, components with different layouts can all be pointed at the same item and display the same content in various ways.
Sitecore requires a search engine to support the Sitecore authoring UI. Content items can be found by searching the content tree. Sitecore search can also be used programmatically to support website search or to support other site functionality such as tag based related item search.
SOLR search is the preferred search engine technology for both development and production installations (in my opinion). For single site installs, Lucene is a valid option, however, Lucene limits Sitecore’s ability to scale and is only suitable for a single server setup, or a developer workstation setup. SOLR requires some work to configure for production systems to enable fail- over redundancy. Keeping SOLR indexes synchronized across SOLR instances requires Zookeeper, and this can be complex to configure. I recommend a service like SearchStax if you need high availability SOLR for your solution.
Sitecore also supports Azure Search, and this is the default setup for Azure PaaS using the ARM templates. Azure Search is a capable search engine, but it is not free and open source like SOLR, so it comes at a cost. Azure search is also limited to indexing 1000 fields. A Sitecore install with SXA will exceed this limitation, so you will have to update your indexing configuration to exclude fields.
Language and Multisite Support
Sitecore ships with decent language support. The basic model assumes a base Sitecore item created as a global english item version. Additional languages can be added from Sitecore’s default list of languages. Once a language has been added, item version for that language can be added with the translated content. Sitecore assumes a one for one translation model. Additional language sites share the same translated content as the base site. Regional content is best achieved by using Sitecore’s multisite capabilities.
Hosting multiple sites in Sitecore is as easy as adding a page node in the content tree and updating the sites configuration file to assign a domain to the new page node.
Workflow and Versioning
Sitecore provides customizable authoring workflow out of the box and a default workflow that can be enabled and used as is. Sitecore workflow can be used for content approval gates and can be setup to prompt approvers via email. Be careful not to overbuild a content workflow, in our experience, simpler is better. See our post on Sitecore workflow for more information -> Best Practices For Workflow In Sitecore.
Sitecore items can be versioned once workflow is setup. This means that content changes to an item are tracked as versions. Item versions track the content changes as well as the author and date the changes were made. Versions make it easier to revert if a content change was made in error. It is also possible to keep a rolling number of revisions (eg. keep the last 3 versions) in order to keep the content database small and performant.
Security and AD Integration
The Sitecore security model allows you to control author access at the item level. Field level access cannot be controlled. I recommend keeping access as open as possible and training users instead of trying to hide things to make it easier (or safer) to author content. Sitecore ships with local security users and roles. The out-of-the-box roles are a good start but you will likely have to add more permissions to these roles to make them effective for authors. The base admin account is created with a new Sitecore install and you can use this account to create more admin accounts and author accounts.
Sitecore can also be configured to authenticate against Active Directory (ADFS or Azure Active Directory).
Sitecore includes a rich API that can be used to interact with the site content items. This API, known as the ItemService, requires authentication to access as it allows for full content management functionality. Items can be created, updated and deleted through this API.
There is a read-only API known as that can be accessed without authentication. This service requires an API key to access, and is useful to create headless web solutions that need to access to Sitecore content but not the Sitecore web page layout and presentation engine.
Every aspect of Sitecore can be customized and extended. Each page request works it way through a processing ‘pipeline’ that can be enhanced to add logic at the request level. Creating layouts, templates (read content types) and components represents only the basics of building on Sitecore. It is also possible to extend Sitecore with new field types and UIs for those new fields, as well as customizing and enhancing the Sitecore authoring UI. There are a number of Sitecore modules that come to mind. Most notably, Sitecore SXA and Powershell Extensions.
Sitecore Rocks is not a module per se, but a Visual Studio plugin that brings the ability to update Sitecore templates and items from within Visual Studio.
Sitecore released the Helix architecture practices in 2015 along with an example project called “Sitecore Habitat”. Helix is a component based code architecture that emphasizes component code isolation in the back end c# projects. It is intended to become the defacto standard for how Sitecore websites are built.
Read the Sitecore documentation on Helix here -> Sitecore Helix Architecture.
Sitecore is a richly featured CMS with flexible functionality out-of-the-box. Sitecore has:
- Great multi-site and multi-language support
- Configurable workflow
- Item versioning with change auditing
- Marketing campaign management
- Site visitor analytics
- Visitor audience personalization
- A-B Testing
So, what is Sitecore - from a developer's point of view? Sitecore is a stable and well organized CMS platform built on Microsoft ASP.net. Sitecore has an almost 20 year history and is backed by Sitecore Corporation. Likewise, ASP.net has a 20 year technology history and is backed by Microsoft which has historically been a very developer friendly technology company. Sitecore allows you to build sites by using a component based layout system, and gives authors the power to author content visually (In the context of the page) using Experience Editor. There is a strong developer community behind Sitecore with an MVP program that encourages blogging and sharing advice and experience.