This blog post provides some guidance on managing versions of items with the Sitecore ASP.NET web Content Management System (CMS).
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.
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: 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: marketplace.sitecore.net/.../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.
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: 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 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: 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.
Hi, I'm new to Sitecore and would like to know if we have to activate the version for it to work (Like SharePoint). If so, where do I activate the version in Sitecore. From your article, it seems the version is auto activated. The reason why I ask this question because I have a brandnew Sitecore site that has version but it only shows 1 version no matters how I edited multiple times it still shows my last edit and only compare the current version with current version which is 1 with 1.
@NLuu: It sounds like you have no workflow configured for this item, or that you do not transition that version from one workflow state to another when you desire versions. Sitecore should create a new version when you edit an item that is in a final workflow state. In that case, I believe you could create versions using features in the UI.
Hi Everyone, I was wondering if there is any method to support de-serializing an item based on a particular language or version? Any suggestions would be appreciated
@Mithun: I can't see any easy way. I think you should be able to remove the other languages from the serialization file before import.