Understanding content versions in Sitecore

Understanding content versions in Sitecore

Understanding content versions in Sitecore Understanding content versions in Sitecore
Director, Solution Delivery
Grant Bartlett

December 09, 2014

The tracking of content changes in Sitecore significantly deviates from the established norm. Learn the ins and outs of versioning and workflows in Sitecore, the product's answer to these publishing tools.

In the publication world, tracking content changes in real-time is common, likely due to the prevalence of Microsoft Word's own tracking functionality. Traditionally, a document is versioned and passed from one individual to the next for approval and edits, with each edit being tracked and identifying the content author who made the change.

In Sitecore, versions are not nearly as in-depth as the process outlined above. Versions do exist and you can compare one version of an item to another, but the level of change tracking typically seen in the publication world, does not exist in Sitecore. This is not necessarily a bad thing, but it should be communicated to your content authors in order to maintain the expectations of using Sitecore's workflow and versions.

In Sitecore, versions are intimately tied to workflow. Together, they ensure content is never live before it has been approved. Let's walk through an example using a simple workflow with three states: a Create/Edit state, an Approve state and a Published state.

Create/Edit state

Version 1

  • Bob creates a new page ContentPageA.
  • Bob adds his content and moves the page to the Approve state

Approve state

Version 1

  • Sue sees ContentPageA in the Approve state and begins reviewing the content.
  • Sue sees some minor spelling mistakes which she updates
  • Sue sees a major issue with the text and sends the updated page (with spelling mistakes fixed) back to the Create/Edit state for rework
  • Bob updates the text and sends it back to the Approve state.

Published state

Version 1

  • Sue reviews the update, confirms the content, and moves the item to the Published state. This is the end of life for version 1 (ie: version 1 is now live)

Once that process has been completed, only one version of the page will exist. All the changes made by Bob and Sue are to the same version of the page. Although Sitecore does track who last edited the content, it does not identify what the individual changed.

Now, let's walk through an edit of the item we just created and published. Like before, the initial workflow state is the Create/Edit state.

Create/Edit state

Version 2: Version 2 gets created, but version 1 is still the site's live version

Bob now has an update for the content in ContentPageA. He moves ContentPageA from the Published state to the Create/Edit state.

Approve state

Version 2: Version 2 is being edited, but version 1 is still the site's live version

  • Bob makes his changes and moves the content to the Approve state.
  • Sue reviews ContentPageA and makes a minor grammatical update

Publish state - Version 2 is now live

  • Sue moves the item to the Published state.

In these steps, you'll notice that while Bob and Sue are updating the content on the page in Version 2, Version 1 remains live. This is how Sitecore ensures content can be edited in the background (Version 2) while not affecting the live version (Version 1) of the content.

If you use Sitecore's version comparison tool, it will show all of the differences that exist in the content between versions 1 and 2, however, it will not show who made the individual changes.

Meet The Challenges Of Today's Digital Economy

Ready to take that first step and rise to your digital potential? Contact Valtech today.
Talk to us
Meet The Challenges Of Today's Digital Economy