Sitecore: When to use UserSwitcher vs SecurityDisabler

Security Disabler will override all security. All security checks will be skipped and code will run unfettered.
It is good for use during prototyping as you can skip creating of a restricted service account.

1
2
3
4
    using (new SecurityDisabler())
    {
        // code here has elevated security priviledges. No access check performed.
    }

UserSwitcher allows a segment of code to run under a specific user instead of current context user
Good for use in production code as it is reduces the attack surface exposure and is much safer.

1
2
3
4
    using (new UserSwitcher(@"sitecore\RestrictedServiceAccount"))
    {
        // code here has security priviledges of the RestrictedServiceAccount.
    }

Sitecore Fundamentals: Data Template Basics

A Data Template (AKA Template) is a blue print for Sitecore items and defines the structure of each type of item in Sitecore.  Each item in Sitecore is based on a template. Sitecore uses items to store various kinds of information in its databases. For example, configuration data, system components, pages, renderings, media, layouts, and even templates are Sitecore items. In terms of object oriented programming a template would be a class and the item an object (or an instance of the class).

Templates in Sitecore are only used for data definition unlike some other CMSs where templates can also mean presentation components. Sitecore uses layouts and renderings to refer to presentation aspects.

Sections:

Each Data Template has zero or more sections that can contain fields to define the structure and properties of a given type of item. Sections are used for logical grouping of fields into related groups in the content editor. When using the API, programmers don’t need not worry about sections when getting content from fields. When defining fields across sections make sure they have unique names as sections are not relevant when it comes to code.

There is no direct corresponding counter part for a section, but in someways they are similar to #region in C#. Sections are only used to group fields in the Sitecore content editor similar to the purpose #region serves in Visual Studio.

Fields:

Fields are used to define properties of a piece of data in the template. They are analogous to Properties in Object Oriented Programming terms. They specify the data type (number, text, droplist, treelist, etc.) and also validation requirements for the field. The data type is also used by Sitecore to pick the UI component to be used in Content Editor interface. For example, a Number type will display a text box and allow users to enter a number. By default, all fields are stored separately per language and per version within a language. They can be marked as Unversioned and/or Shared to control how many the field is stored per language and per version for a given language.

Sitecore Field Types are organized into the following Categories:

  • Simple Types: These types implement components such as Single-Line Text, Multi-Line Item, Rich Text (HTML), Date, Datetime, Integer, Image, File, and Checkbox. Sitecore stroes values for most of these types as plain text.
  • List Types: These types include Checklist, Droplist, Grouped Droplink, Grouped Droplist, Multilist, Treelist, Treelist ex.
  • Link Types: These include Droplink, Droptree, General Link
  • Developer Types: These are intended for developer use. Icon field type, IFrame field, and Tristate field are developer types.

Developers can also implement custom field types. VideoEmbed, Map (Lat/Lon), Color Picker are good examples of custom field types.

Template Inheritance:
Each template is Sitecore can inherit from zero or more base templates which can in turn have their own base templates. Sitecore supports both sequential and multiple-inheritance for templates. In the screenshot below the Page Template inherits from several other templates (MetaData, Seo, Navigation, Taxonomy, and WorkflowBase) explicitly and from the Standard Template implicitly.

Most Data Templates will eventually inherit from Sitecore’s built in Standard Template that defines sections and fields common to all items in the CMS. It is possible to inherit from the same base template more than once as a result of multiple inheritance. Sitecore will pick only the first occurance of that base template.
Sitecore will combine fields from all templates in the hierarchy. When multiple base templates contain a common field the Sitecore UI will merge the fields to avoid duplication.

Also avoid any cyclic dependencies in the template inheritance hierarchy as this will most likely result in a Stack Overflow or Out of Memory exception at runtime. This often happens when developes modify the base templates associated with the standard template or its base templates.

Standard Template:
Standard Template is Sitecore’s default base template that most other templates inherit from either through the inheritance chain or implicitly. If a template does not inherit from another template, it implictly inherits from the Standard Template. The Standard template inherits from multiple templates each defining a section in the standard template. These are defined in /Sitecore/Templates/System/Templates/Sections in the Content Editor. These defines sections such as QuickInfo (shown to admins), Security (who can access an item) and Workflow (publishing) that are relevant to all items in sitecore. Most fields in Standard Template represent system values that are common to all verions in all languages for an item.

You can explictly choose not to inherit from the Standard template by setting NULL Guid as a base template for your template. Standard template is like a uber base class in the object oriented programming paradigm.

Standard Values:
Standard Values provide default values for all fields defined in a Template and its base templates. It is facilitated by special item named __Standard Values which lives as a child of the Template in Sitecore. This item is of the type defined by the Template. The sole purpose of the __Standard Values item is to provide default values when an item’s field does not contain a user specified value (in other words the value is NULL). Standard values can be used to store settings that apply to all concerned items. This way they can be centrally administered. It is best to define Layout Settings, Initial Workflow, and Insert options in template standard values rather than individual items.

Tokens:
Tokens are special strings that can be specified as values in the Standard Template that get expanded when an item is created.
For example, the $name token can be specified for a field in Standard Values which will set the field value to be the name of the item. This token replacement/expansion only occurs at the time of the item creation and future item name changes will not be carried over to the field value. Other such built-in tokens are $id, $parentid, $parentname, $date, $time, and $now. Developers can add their own custom tokens by customizing the expandInitialFieldValue pipelines.

Figure below shows Standard Values and Tokens in use:

Best Practice Tips:

  1. Try to create one section per template and then inherit from multiple base templates for your final data template. This makes it easy to create and manage your new data template containing several sections.
  2. Do not make changes to default templates provided with sitecore (anything under /Sitecore/Templates/System) as it not only can cause loops in the inheritance but can also block your sitecore upgrade path.