Items, Languages, Versions, and Revisions in the Sitecore ASP.NET CMS

This blog post contains information items, but more importantly languages of items, versions of items in languages, and item revision identifiers in languages of items in the Sitecore ASP.NET web Content Management System (CMS).

Sitecore abstracts storage repositories such as relational databases as hierarchies of items that can contain any type of data. For each item, you can create any number of versions in any number of languages. The existence of an item does not indicate the existence of a version in any language. You do not need to create versions in any language, although Sitecore creates a version in the current content language when you create an item.

You can create versions in languages that you have not registered, but I strongly encourage you to register the languages that you will use in advance. Two benefits of registering languages are that you can iterate the language definition items and that you can apply security to languages. Configure languages under /sitecore/system/Languages.

Sitecore publishes languages individually, meaning that you must first publish an item, a branch of items, or an entire database in one language, and then another; you cannot publish each item in each language before publishing the next item without implementing a custom solution. Publishing ensures that at most one version of each item exists in the publishing target database; only the Master database contains multiple versions. Sitecore uses publishing restrictions including workflow state to determine whether to publish the item and which version to publish in each language.

By default, you can translate each field of an item. If you want all versions of an item in a language to contain a common value, you can designate that field as unversioned. If you want all versions of an item in all languages to contain a common value, you can designate that field as shared.

Multiple versions of an item can be in different states of different workflows at the same time. Be aware (or beware) that Sitecore does not store previous values of shared and unversioned fields, and that publishing a version of an item in a language includes unversioned and shared fields. Put another way, you cannot reverse changes to shared and unversioned fields, and you cannot prevent Sitecore from publishing changes to unversioned and shared fields, which in the case of shared fields can affect versions of items in multiple languages.

Excluding shared and unversioned fields, when you update a field in an item, we almost always update a version in a language within that item. The Fields collection of the Sitecore.Data.Items.Item class exposes the fields in a single language, though the class itself exposes the item and all of its versions in all languages. Changes to unversioned fields apply to all versions of the item in that language; changes to shared fields apply to all versions of the item in all languages. Very few other operations including rename and move apply to the item and all of its versions in all languages.

Unless you pass specific parameters to the relevant APIs, when you update a field, Sitecore updates the revision identifier for that version in that language. While version identifiers are numeric, revision identifiers are GUIDs. Sitecore stores the revision identifier in the Revision (__Revision, Sitecore.FieldIDs.Revision, Sitecore.Data.Items.Item.Statistics.Revision) field in the Statistics section of the standard template. Smart publishing skips items for which the revision identifier in the source database to the revision identifier in the publishing target database do not differ.

If you have additional information about items, languages, versions, and revisions, please comment on this blog post.