Sitecore Blog: @sitecorejohn blog

Sitecore CMS 6.4: Cloning

By John West, October 14, 2010 | Rating:  | Comments (35)

screen shot of Sitecore ribbon for cloning

This blog post describes cloning, a new feature in version 6.4 of Sitecore's ASP.NET web CMS. For more information about Sitecore CMS 6.4, see my previous blog post, Sitecore 6.4 Features.

Sitecore 6.4 introduces cloning, which creates a dynamic duplicate of an item or branch, and provides notification when cloned items change. You can expect information about clones to appear in the guide to Reusing and Sharing Data.

A clone is an item based on the data template associated with the cloned item. Rather than inheriting values directly from standard values, clones inherit field values from the cloned item. In clones, Sitecore uses the __Source field in the Advanced section of the standard template to specify the cloned item.

Cloned items do not inherit the following fields defined in the standard template:

  • Lock
  • Workflow
  • Workflow State
  • Updated
  • Created
  • Updated By
  • Created By
  • Source
  • Revision

When you create a clone, under the new item, Sitecore creates clones for each of the descendants of the new item.

You can create clones of items or entire branches of the content tree. You can override individual values in cloned items.

After you update a cloned item, add a descendant to a cloned item, add a new version to a cloned item, or delete a version of a cloned item, the Content Editor displays notifications in the clones regarding those changes, and provides commands that let the user resolve the change.

If you create a clone of a clone, the second clone inherits values from the first clone, then from the cloned item, and then through the standard values chain.

To clone an item, in the Content Editor, select the item to clone, click the Configure tab, and then in the Clones group, click Clone. In the dialog that appears, select the item under which to create the clone.

To convert a clone into an item, copying field values from the cloned item, in the Content Editor, select the item, click the Configure tab, and then in the Clones group, click Unclone.

When you delete a cloned item, Sitecore confirms that it should copy field values from the cloned item to its clone before deleting the cloned item.

To view information about clones in the Quick Action bar to the left of the content tree in the Content Editor, right-click the Quick Action Bar, and then click Cloned Items.

In clones, the text [original value] appears in the title of fields that do not override the cloned value.

Publishing converts cloned data to field values.

The Sitecore 6.4 UI does not support cross-database clones, but this seems inevitable.

The current UI always includes descendants when cloning an item, but change there seems inevitable as well.

When you change the data template for a clone or cloned item, fields with the same IDs will maintain values, but fields with different IDs will lose values, even if they have the same names.

Of course for now you can override everything to do exactly what you need, but you can also expect Sitecore to add the most requested features. For example, Sitecore could introduce rules to manage change notification.

Please add any information or questions about clones by commenting on this post.

Tags: API, Architecture


  • Have you thought about if clones should have the header tag for duplicated content automatically?

    - Kasper Pagels
    October 23, 2010 at 7:10 AM

  • > the Content Editor displays notifications in the clones regarding those changes, and provides commands that let the user resolve the change. Is there any intention to add functionality to automatically update unlocked clones if you save a change on a cloned item? As much as I've come to dislike proxies, this seems to be a more labor-intensive way to keep your data in sync if you rely on them heavily.

    - K.Adam White
    November 05, 2010 at 5:40 AM

  • @Kasper Pagels: If you mean that presentation should include specific meta headers, I haven't developed anything. It seems that you could use a pipeline processor, or a presentation component. I wonder if there are cases where one would not want this header in cloned items.

    - John West
    November 08, 2010 at 10:15 AM

  • @K.Adam White: When you change a field in a cloned item, Sitecore automatically applies that change to fields in clones that do not override the value in the cloned item. Do you mean that if the item is unlocked, Sitecore should not notify the user about the change?

    - John West
    November 08, 2010 at 10:15 AM

  • > "When you change a field in a cloned item, Sitecore automatically applies that change to fields in clones that do not override the value in the cloned item." No, this answers my question; I had misunderstood, and thought the update had to be manually enacted even if you had not overridden the value. Thank you for the clarification, I am excited for this functionality upgrade.

    - K.Adam White
    November 08, 2010 at 11:07 AM

  • Worth noting that though "When you change a field in a cloned item, Sitecore automatically applies that change to fields in clones that do not override the value in the cloned item." this change won't be in effect on the web until the clone is published.

    - James Walford
    March 31, 2011 at 10:08 PM

  • Some relevant links:

    - John West
    April 06, 2011 at 9:44 AM

  • 6.5.0 Update-4 (rev. 120427) introduces the ItemCloning.NonInheritedFields setting, which specifies the fields that clones do not inherit.

    - John West
    May 08, 2012 at 12:17 PM

  • If i am looking in the admin/dbbrowser (masterdatabase) i see that a cloned item got the source property filled in. But when i navigate to the same clone in the web database i see that the clone(item) has no source field filled in .. Is that what you say by Clone items does not support cross-database clones, but this seems inevitable. I wanted to set a canonical tag when a visitor requests a cloned item. Do you have any ideas how to do that?

    - Menno Visser
    May 09, 2012 at 1:41 AM

  • Hello @Menno, This is a different issue: when you publish a clone to a target database, Sitecore converts that item into an actual item; it is no longer a clone. I don't remember the exact reason for this. I think one solution may be to intercept item publishing and set a checkbox in the item or otherwise indicate it is a clone. Someone seems to have tried this: One thing to beware of with this is that you probably don't want Sitecore to update the revision ID or trigger events for the items that you update. I don't know if the code shown addresses those issues (maybe it only updates an in-memory representation of the item before writing it to the database, which I think would address the issue). If you end up using EditContext() for this, pass false as the second and third arguments to its constructor (see for a little more detail on that). There *might* be another way to check for a cloned item in a publishing target database; it might be worthwhile to contact Whatever you do, please comment further on this blog post to describe your solution. Regards, -John

    - John West
    May 09, 2012 at 7:16 AM

  • Hi John, Is there any solution for the below issue ? i just posted from your blog only "i see that a cloned item got the source property filled in. But when i navigate to the same clone in the web database i see that the clone(item) has no source field filled in" I'm exactly facing the same issue in my server , I have CD and CA servers and i'm using cloning through work flow .all of a sudden links are missing from cloned items there any solution for this Thanks in advance

    - vidya sagar
    August 08, 2012 at 8:39 AM

  • Cloning looks a good new feature. When I edit a field in a clone, I notice that the [OriginalValue] tag disappears as I would expect. However once this has been done, is there any way to re-establish the link for that field to the parent item, or is the link lost forever.

    - Justin Crossley
    October 29, 2012 at 7:16 AM

  • @Justin: I thought you just reset field values in the clone to their values in the cloned item as you would reset fields to their standard values for any non-clone item (the Reset command in the Fields group on the Versions tab, the Reset command in the Layout group on the Presentation tab, the Reset command in the Insert Options group on the Configure tab, and possibly other specific commands (I can imagine one on the Security tab)). If that is the case, then clones always inherit values from cloned items; the only way to reset a field in a clone to the standard value defined in the data template for that clone would be to reset that field in the clone AND the cloned item (you could also copy the standard value into the clone). Regards, -John

    - John West
    October 29, 2012 at 12:03 PM

  • When you create a new subitem for an item that has been clones, it seems you have to manually go to each clone and accept that a subitem be created beneath the clone. Is there any way to not have to do this? For a new solution we will have several clones of one source and the customer won't want to go to every single clone and accept a subitem. It would be much easier and user friendly to have subitems always appear in the clones without any questions. The same also applies to instances where content authors has overridden a value in a clone, then a "power author" changes a value in the source item. How can this change be applied to all clones without the clones having to manually accept the change? Cheers

    - Glenn Thomas Hvidsten
    November 12, 2012 at 5:05 AM

  • @Glenn: I know there has been internal discussion about this but I don't have details about any progress. You might contact customer service/support and see if they have ideas, but I will run this by an engineer I know worked on clones. I think there might also be some SDN forum threads about this but they might not be easy to find and would not necessarily have a great answer.

    - John West
    November 13, 2012 at 7:38 AM

  • @Glenn: From the engineer: This is possible (while not easy to implement) by subscribing to the SavedItem and CreateItem events and if the item (or parent) has any clones, get related notifiations through item.Database.NotificationProvider and Accept() those of type ChildCreatedNotification and FieldChangedNotification. The pseudocode would be: Database_SavedItem() { foreach (var clone in item.GetClones()) { foreach (var notification in clone.Database.NotificationProvider.GetNotifications(clone.Uri)){ if (notification is FieldChangedNotification && some other tests) { notification.Accept(clone); } } } } Database_CreateItem() { var parent = item.Parent; foreach (var clone in parent.GetClones()) { foreach (var notification in clone.Database.NotificationProvider.GetNotifications(clone.Uri)){ if (notification is ChildCreatedNotification && some other tests) { notification.Accept(clone); } } } } The subscription should take place after NotificationManager has subscribed to the database events (I think, <hooks/> configuration section is fine for that). The normal item:saved and item:created events may also work.

    - John West
    November 15, 2012 at 7:47 AM


    - John West
    February 08, 2013 at 10:27 AM

  • Hi John, Not sure if this will slip through the gaps as it's a relatively old blog post. We've introduced some new fields to track when and where items are published to but want to stop these fields from being copied over to the clone. I have retrospectively added: <setting name="ItemCloning.NonInheritedFields" value="Last Published|Last Published By|Publishing Targets" /> But fields which are already cloned seem to keep their clone link. Is there any way to break this link for these cloned items? Or are we doing something wrong? :) Thanks, Owen

    - Owen Niblock
    June 25, 2013 at 11:43 PM

  • @Owen: To confirm, it works the way you want when you create a new clone, but your old clones don't work the way you want? I didn't check but I assume the logic that applies that setting occurs when you clone an item. Since you cloned the items before you changed that setting, those clones probably have null in those fields, causing them to retrieve the value from the cloned item, where an actual value in those fields (even a blank) should override that cloned value. I think one solution would be to write some script that iterates all your clones and changes those nulls to actual values. I could probably help with that if needed, as I've done a few similar things.

    - John West
    June 26, 2013 at 6:50 AM

  • Great, I'll try that. We've got a tool we can adapt to process the tree. Thanks

    - Owen Niblock
    June 26, 2013 at 7:02 AM


    - John West
    October 24, 2013 at 3:41 AM

  • Use a save handler to accept changes automatically:

    - John West
    August 08, 2014 at 5:35 AM


    - John West
    August 15, 2014 at 7:09 AM


    - John West
    February 04, 2015 at 3:46 AM


    - John West
    June 18, 2015 at 5:51 PM


    - Tamas Molnar
    July 31, 2015 at 7:09 AM


    - John West
    November 07, 2015 at 3:26 PM

  • Is it possible to clone dynamically within Sitecore when an article is saved within different location?

    - Jasvinder Bawa
    December 21, 2015 at 10:52 PM

  • Yes, it would be possible to programmatically create a clone within the "item:saved" event in Sitecore with the necessary logic for location. Just wondering what type of business problem you are trying to solve. I'm not 100% sure what your case is but I would take a quick look at Sitecore wildcard items to double check if they will meet your needs. In general, I recommend wildcard items unless you absolutely need two separate duplicates of the same content item (ie: they could diverge in the future). If the content items will always be identical then wildcards is a great option to consider. Good luck!

    - Scott Mulligan
    December 22, 2015 at 1:35 PM

  • I think that an item:saved event would work, but the rules engine can have advantages in general, and may have specific advantages in this case. Rather than hard-coding when to invoke your logic, or passing complex configuration to your event handler, you could just define rules. It can be a bit more work, but much more flexible and maintainable. I agree with Scott that I would first consider alternatives to the entire approach.

    - John West
    December 22, 2015 at 1:53 PM

  • Thx for the update. I'm trying to figure out "item:saved" event, how it can be accessed and program inside it. The problem @ my end is - I'm creating a base article which is applicable to different dept and each dept will have their own update and WF. I think this option of cloning can help me. If there is any other approach, I would love to know.

    - Jasvinder Bawa
    December 22, 2015 at 6:23 PM

  • I think that cloning could work for this. 1. Can you describe the optimal use case for the author? 2. Does every original article always appear for each department, or 3. how does the author/editor specify the departments for which a new article appears? 4. Would that list of departments ever change (5. would an article that on its creation did not appear for one department later appear for that department?) Even if you think that you could use item creation to trigger your logic, I suggest that you apply your logic on save rather than create.

    - John West
    December 26, 2015 at 2:57 PM

  • Here are the answers 1) Author will create an article in generic location and select to which department it applies and saves 2) No, The article will only appear if author has selected the department while creating an article 3) Departments will be checkbox list hopefully defined in the Base 4) Yes, it can change 5) No, by default the article will not appear for the new department, if it needs to appear then author has to go to article and select the new department along with existing dept and on Save it will clone to new dept. At this time the existing dept. will have a new version into their respective areas.

    - Jasvinder Bawa
    December 28, 2015 at 8:00 PM

  • I would probably use an item:saved event handler rather than item:saving event because you would want to clone the item after the changes commit. The event handler would abort if the item is a clone or is not one of the types items that gets cloned (does not contain the field to select departments). Otherwise, for each selected department, if the clone does not exist for that department, then call the API to clone the item to that department, and possibly APIs to alter its workflow, workflow state, lock holder, owner, or otherwise.

    - John West
    January 06, 2016 at 5:12 PM

  • Also, abort if the item is the standard values item for the data template.

    - John West
    January 08, 2016 at 5:02 PM

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