12

Sitecore recommends limiting number of items to up to 10 versions per item.

The version manager module can be used to limit the number of item versions. This can either be run periodically, or when the number of item versions goes above a set number. When run, the module deletes old versions of the item.

I recall that this module used to require the user running the operation to have permission to delete in order for the old version to be removed.

Rather than delete old versions after a certain limit, we want it to only delete versions which aren't either currently on live, or queued up to go live via publishing restrictions / lifetime. This way, the module doesn't end up "unpublishing" items, regardless of age or version count. Additionally, rather than delete the version, we would like to copy the version being removed to an archive. Copying to the archive will preserve references to any datasources, but we would also like to see if there is a way to take a snapshot of any dependencies on the item being archived.

I would be interested to see how others have dealt with ensuring version numbers are kept low, while continuing to support the stacking of future items, and keeping an archive, in order to be able to view past versions.

Improve this question
1
  • For reference, recommendation of limiting item versions to 10 comes from CMS Performance Tuning Guide (Sitecore CMS 7.0-7.2), section 6.2.5 says "Sitecore recommends that you store 10 or fewer versions of a particular item. However, this number may be higher based on company policy that dictates that number of required versions to be stored. Also, Sitecore recommends running the Version Manager shared source module to maintain the number of stored versions": sdn.sitecore.net/upload/sitecore7/70/…
    – Alex S
    Commented Feb 4, 2019 at 16:33

2 Answers 2

Reset to default
3

Trigger Auto-Archiving

You could write a publish:end:remote event that kicks off some logic to find all item versions "eligible for archiving," based on your criteria. You can then archive those versions that are n versions behind the latest.

Archiving

Now that your auto-archiving logic is created, you need to actually perform the archiving. How you do this is really up to you, as there are many was to create an archive. My preference is to create a folder item as a sibling of the home item and use permissions to ensure that only authenticated users with a particular role can view it. In your code, you would use a SecurityDisabler when moving the item, so access rights shouldn't be an issue for the "archiver" logic.

Preserving References

As mentioned in the OP, references on the item being archived to other times will be preseved, and it looks like this is desired. However, it looks like you also want to be able to preserve references to the item being archived for later viewing. You could use the links database to GetReferrers, and then record the resulting list as a list of item IDs.

I have to ask why you would want to do this. If those items are deleted then this list is meaningless. The same goes for recording the referrers as item paths, only now you have to worry about an item-rename making the whole or part of the list meaningless. Bottom-line: unless you plan to make an entire historical record of every item that you've ever had in the system (and this would be a LOT of work if you want to make it meaningful) then I wouldn't advise doing this.

Breaking References

It was implied by the OP - though not explicitly stated - that you will need to break links to the items that you are archiving. I haven't done this myself, but you should be able to replicate the logic for breaking links that is fired when deleting an item. Don't forget to do this, or else you will have items that are not archived referencing items that are archived.

Improve this answer
1
  • 1
    Such logic can not be added to publish:end:remote as you can get only root item got published, not all items/languages/versions, etc. and yet master DB will not be accessible from there, so it's not a good approach. It's always good to have this logic implemented on a scheduled agent on CM environment.
    – Yogesh Patel
    Commented Oct 13, 2016 at 22:30
5

Update: I've recently written about this on my blog and created an SPE script with quite a nice UI to do this for you:

http://www.flux-digital.com/blog/removing-unneeded-sitecore-versions-spe/

To add to this, there are some modules out there for archiving versions: https://marketplace.sitecore.net/en/Modules/Version_Manager.aspx

There are some good blog posts about options for archiving too:

https://community.sitecore.net/technical_blogs/b/sitecorejohn_blog/posts/rules-engine-actions-to-remove-old-versions-in-the-sitecore-asp-net-cms - a nice solution using the rules engine

https://sitecorepm.wordpress.com/2012/11/30/introducing-the-sitecore-version-pruner-shared-source-module/

http://robearlam.com/blog/extending-sitecore-revolver-to-remove-old-versions/

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.