SharePoint to Sitecore dictionary
Ever heard of sublayouts or renderings in Sitecore and wondered what those are? Wonder no more!
Whether you are a SharePoint person looking into Sitecore, you have colleagues in your organization who work with Sitecore or you are simply curious, following is my take at comparing the different concepts in SharePoint and Sitecore and what the most important differences between them are.
The list is not exhaustive and if you have suggestions for how it could be improved, I'd love to hear from you.
|Master Page||Layout||In Sitecore you can configure a different Layout for each item but Sitecore recommends to use one Layout per device per site|
|Device Channel||Device||You can use Devices in Sitecore to control how data is presented. Although Sitecore supports adaptive layouts using Devices (similarly to Device Channels in SharePoint) more frequently responsive design is being used for cross-device presentation. Devices are being used for things such as JSON output to provide data to mobile and external applications|
|Page Layout||Sublayout (WebForms) or Rendering (MVC)||The biggest difference between Page Layouts and Sublayouts/Renderings is that Sublayouts/Renderings can be nested to build a more componentized website. Component-driven development in Sitecore is essential for supporting Experience Management|
|Web Part Zone||Placeholder||Placeholders in Sitecore can be static (where components are configured by developers) or dynamic where content editors can manage components using the Experience Editor|
|Web Part||Component||A component in Sitecore consists of an .ascx/.cshtml file deployed to the file system and a definition item in the content tree that registers the component file with Sitecore. For each component you can specify different settings amongst which parameters and the corresponding UI for editing their values|
|Content Type||Data Template||The biggest difference between the two is that Data Templates in Sitecore support inheritance from multiple base Data Templates (in code terms more like interfaces than base classes). In Sitecore you could for example have a SEO Data Template that would contain SEO-related fields and an Publishing Data Template that would contain fields like publishing start and end date. By creating a new Data Template that inherits from both those templates you would have a template that allows you to optimize your item for SEO and have scheduled publishing|
|Column Group||Section||No particular differences|
|Column||Field||In Sitecore Fields are created always as a part of Data Template and cannot be reused across the different Data Templates. You can create Fields with the same names in different Data Templates but internally they will be treated as two different fields and both will appear in the UI. The only way to reuse Fields in Sitecore is through creating base Data Templates|
|Versioning||Versioning||Sitecore knows two types of versioning: languages (similar to Variations in SharePoint) and numbered versions. For numbered versions Sitecore supports only major versions. Drafts can be created only through workflow where draft is merely a state and not a version (so no 0.1, 0.2, etc.)|
|Workflow||Workflow||Sitecore supports workflows on items. At the same time an item can participate in only one workflow. Each workflow has an initial and one or more final states and only items in final states are published. In most common scenarios standard workflows available with Sitecore cannot be cancelled by the person who started it (ie. content editor who started approval process cannot cancel it but the person with approve permissions can)|
|Timer Jobs||Scheduled Tasks||Scheduled tasks in Sitecore run as a part of the w3wp process and are disabled by default. Functionality such as scheduled publishing or other scheduled tasks must be explicitly enabled to work|
Everything is an item
One of the biggest differences between SharePoint and Sitecore is the fact that in Sitecore nearly everything is an item. This seems confusing at first but it offers great capabilities. Imagine for example that in SharePoint you would be able to configure who is allowed to work with which Web Part Zones, which Web Parts or types of Web Parts are allowed in which Web Part Zone and which Web Parts can be swapped. Such capabilities, and more, are available in Sitecore out of the box thanks to the fact that everything is an item in the content tree and can be configured by developers using standard properties such as permissions or links.
It takes a moment to understand the different capabilities in Sitecore if all you have is SharePoint experience but after you map them to the SharePoint concepts you already know, things get a bit easier. I hope you will find this overview helpful and please reach out if you have any feedback.