X

Register now for unlimited access to Sitecore resources.


Already have an account? Log in now

*{0} must be filled in.
*{0} must be filled in.
*{0} must be filled in.
*{0} must be filled in.
*{0} must be filled in.
*{0} must be filled in.
*{0} must be filled in.
X

Request a demo

It’s easy to get started. Sign up for a personalized demo.

*{0} must be filled in.
*{0} must be filled in.
*{0} must be filled in.
*{0} must be filled in.
*{0} must be filled in.
*{0} must be filled in.
*{0} must be filled in.
Sitecore Blog: @sitecorejohn blog

Thoughts on Versioning Items with the Sitecore ASP.NET CMS

By John West, July 12, 2013 | Rating:  | Comments (9)

This blog post provides some guidance on managing versions of items with the Sitecore ASP.NET web Content Management System (CMS).

This post is about versioning content items. Code (including CSS, JavaScript, images, other media, and anything else referenced directly by code rather than determined dynamically by code at runtime), the assemblies generated from source code, and anything else maintained by developers should follow a standard source code management and release process completely separate from but in some cases synchronized with the deployment of content. Developer components include data templates, which Sitecore maintains as items, but should follow code release practices. For such resources I highly recommend the Team Development for Sitecore (TDS) product by Sitecore technology partner Hedgehog development.

The Sitecore default configuration and general recommendation is that each version relates to a complete workflow cycle. To summarize, when a user creates an item, Sitecore creates a version in the current content language and initiates the workflow for that version. After that item completes its workflow, if a user edits the item in that language, Sitecore creates a new version and initiates its workflow. In some cases when working as a Sitecore administrator, Sitecore does not create new versions or initiate workflows.

This process can repeat indefinitely, resulting in a theoretically infinite number of versions. Practically, you should limit the number of versions in any language, typically by removing old or irrelevant versions (for example, versions that differ from other versions by only a few typos). There are no specific rules here, but I would suggest 10 or 30 versions as a general rule of thumb. Another approach would be to prune versions older than some number of days, or some combination (keep versions newer than some number of days unless the number of versions exceeds a given number). Versions are not intended for audit, for which Sitecore provides other facilities. If you choose to trim versions, you may wish to first serialize the items so that you have another copy of the data beyond that provided by your relational database backups.

Users can also create versions manually, which means that more than one version of an item in a single language can go through workflow concurrently. Sitecore always publishes the highest version number for which there are no publishing restrictions, including workflow state. To create a new version in the Content Editor, select the item and language, select the Versions tab, and then click Add in the Versions group. Other commands on this tab let you work with other versions and languages, including visual comparison of the differences between versions and manual translation of one language to another.

Some organizations may choose to implement a workflow action or other solution to create a new version each time content moves from one workflow state to another, or from specific workflow states to other specific workflow states. In this case, the action may set publishing restrictions to prevent publication of the previous unapproved versions, and update the workflow state associated with those versions to prevent them from appearing in the workbox. Another workflow action or other process could remove those intermediary versions when the workflow completes, leaving only the published versions. Otherwise, this would lead to a higher number of versions, in which case pruning versions would be more important. An even more version-intensive approach would be to create a new version each time a user unlocks an item, or even more intensively, each time a user saves an item. This provides the most detailed version trail, but could lead to a very large number of versions.

In the Content Management (CM) environment, the number of versions of an item in a single language can affect usability, and the number of versions in all languages can affect performance.

In my experience, users rarely revert to a previous version. If they do, they revert to the previous version, not an earlier version. To achieve this goal in Sitecore, simply delete the current version (in the Content Editor, select the appropriate item, language, and version, click the Versions tab, and then click Remove in the Versions group). More often, they remake changes, possibly by cutting and pasting from a previous version. I think that even developers rarely revert to previous versions, other than discarding their most recent changes.

If you have any additional insight about version management with Sitecore, or simply to indicate your versioning strategy or the number of versions you choose to maintain, please comment on this blog post.

Resources

Tags: Architecture, Infrastructure

Comments

  • Hi John,

    You said "Versions are not intended for audit, for which Sitecore provides other facilities". What are you referring to exactly?

    I would generally agree with your comments about versioning in that it is rarely used. Having said that, I know that a content editor can be annoyed when they forget to manually add a version and have to manually re-write something. Either because of an error, or simply a temporary change. Fortunately, it is a rare occurrence.

    - Jonathan Hyatt
    July 23, 2013 at 9:11 AM

  • @Jonathan: By default, you get some audit in the Sitecore logs, which I think you can configure to write separately from the system logs. For some types of reporting, you can use components such as this:

    http://marketplace.sitecore.net/en/Modules/Advanced_System_Reporter.aspx

    Remember your database backups. You can implement workflow actions, lock/save/unlock event handlers, UI customizations, and/or other features such as a custom database for reports. You might want to look at some of the lock configuration settings, which I have never changed. There are other relevant features that I have not explored, such as the history engine.

    - John West
    July 23, 2013 at 9:47 AM

  • http://marketplace.sitecore.net/en/Modules/Database_Changes_Tracker.aspx

    - John West
    October 23, 2013 at 4:18 PM

  • Hi John,

    Thanks for blogging about this. I've noticed an interesting, seemingly undocumented (if it is, please correct me) feature of Sitecore versioning. If you select "Add Version" from the version ribbon, Sitecore adds a new version of the item. It creates the new version by copying field values from the *version you are currently looking at* and NOT the latest version, as one might expect. This is very confusing and has led to some, until now, unexplained lost content on our latest version.

    To give an example, say you have an item with the field "Title" with 2 versions. Version 1 has Title = "v1" and version 2 has Title = "v2". Now do the following:

    - Select Version 1 from the versions drop down so you can see version 1. You see the title is "v1".
    - Click "Add Version" from the versions ribbon.
    - Version 3 is created and in edit mode. The title is "v1"
    - Version 2 still exists with title "v2" but this field value has been completely lost.

    Is this intended behaviour or is it a bug? We're using Sitecore 6.4.1

    - Owen Wattley
    August 22, 2014 at 3:08 AM

  • @Owen: While some might consider it a bug, I would call this a feature rather than a defect. This allows you to create a version based on an old version, which is a valid operation that I think would not otherwise be possible. If desired, I believe that it should be possible to override this behavior (that command) to always retrieve values from the latest version in the current language. At the very least, it could confirm that the user wants to create the newest version based on an old version, or suggest that they select the current version before creating a new version.

    - John West
    August 22, 2014 at 9:13 AM

  • @John Thanks for clearing that up. I agree that making it clearer to the user what is going to happen when they click the button is a good option (i.e. a prompt). I shall look into this for future development. It might be worth putting that in as standard functionality since it's so easy to get confused.

    Cheers!

    - Owen Wattley
    August 22, 2014 at 9:23 AM

  • @Owen: I agree, it could be standard functionality. I suggest filing a feature request and posting its ID here so that others can reference your case if they find the same issue. I would like to blog about the command override but likely will not find time.

    - John West
    August 22, 2014 at 10:15 AM

  • http://www.sitecore.net/Learn/Blogs/Technical-Blogs/John-West-Sitecore-Blog/Posts/2014/08/Creating-New-Versions-from-Existing-Versions-in-the-Sitecore-ASPNET-CMS.aspx

    - John West
    August 25, 2014 at 4:53 PM

  • https://marketplace.sitecore.net/Modules/Sitecore_History_Viewer.aspx

    - John West
    September 16, 2014 at 2:11 AM

Commenting is temporary disabled due to maintenance work.

*{0} must be filled in.
*{0} must be filled in.
*{0} must be filled in.