Clones and Datasources

Clones and Inherited Fields

When you clone an item in Sitecore you will have a copy of the item you cloned with a live link to the source (the origin). It is unlike the actual copy (or duplicate) that creates a detached copy. To create a clone Sitecore will reset the values on all the fields on the copied item and will later use the Source field to propagate the values from the clone's origin. This is what makes clone a clone. As long as you don't modify the fields on the clone it will be showing the values form the origin as if it tracked everything that happened to the origin item. 

There's a list of fields that Sitecore doesn't let the clone inherit from the origin:

• FieldIDs.Updated,
• FieldIDs.UpdatedBy,
• FieldIDs.Revision,
• FieldIDs.Created,
• FieldIDs.CreatedBy,
• FieldIDs.Source,
• FieldIDs.Workflow,
• FieldIDs.WorkflowState,
• FieldIDs.Lock

Values of these fields will be copied over at the time the clone is created and detached from the origin.

You can further customize the cloning behavior and tell Sitecore not to inherit some of the fields you want your clones to control. You do so via:

<setting name="ItemCloning.NonInheritedFields" value=""/>

The default value is an empty string. If you wanted, for example, to detach the layout you would add _Renderings or its ID into this "|" separated list. Like this:

<setting name="ItemCloning.NonInheritedFields" value="__Renderings"/>

Datasources

In the component-oriented Sitecore architecture (like the one advocated and enabled by SCORE) your page's information architecture is built out of multiple components, many of which have their own datasources, many of which are local to the page item (the ./Content convention):

The reference to the Datasource is a GUID in the page item's presentation details:

In the example I am showing here the highlighted GUID is the ID of the Content Spot item under some-test-content-page/Content/Spots.

Smart Copy/Clone/Duplicate

SCORE has an extension that makes copy, clone, and duplicate processes smarter by correctly repointing the inward links in the copy to point to the copy's child items, not the origin's child items. Let me illustrate it with an example. Say we have an item A that has a child item B that has a child item C:

A
|
 -- B
    |
     -- C 

Item B is a datasource item for a component used on item A (that would be a GUID reference in the __Renderings fields that we illustrated above). Item B happens to have a field on it that points to item C. Let's say it's a Droplink field so the value is a GUID of item C. And finally, item C refers to item A in its rich text field in the <a> tag and that would be a content path value in the href attribute. 

When we copy or duplicate item A into an item A' all child items and field values will be copied. Without SCORE's smart copy/clone/duplicate the new item A' and its children will point back at item A. The datasource GUID in the item's A' layout details will point at item B, not B' and so will the link in item B' and the <a> in item C'. 

SCORE's event handlers (for copy and duplicate) and a pipeline processor (for clone) will ensure the links are correctly repointed so that a datasource on item A' points at the new copy B', a link in B' points at C', and the <a> in C' points at the A'. Any reference or link outside of the copied item is left intact in the copy

Smart Clones and Inherited Fields

Now let's go back to the clones. In the scenario above a clone A' will not actually have any field values of its own by default. All the fields (including layout details) will be reset and read from A. That's what makes clones what they are. If SCORE were to repoint all the inward links in a clone to properly point within itself it would break the inheritance for all modified fields:

 The most noticeable effect of this behavior will be on the layout field. Clones by default will inherit the layout from the origin. This includes all datasource links pointing back to the origin. It means that:

Recommendations

As of right now in the latest SCORE (1.3 at the time of this writing) there's no mechanism that would support localizing cloned local datasources to the clone and yet keep propagating the layout changes back to it. You basically have three choices:

1. Inherit the layout field (this is the default) and just know that every time you modify the clone int the page editor - you are actually modifying it at the origin.
2. Disconnect the __Renderings field by declaring it non-inheritable and pay the price of not receiving (or propagating) changes to the layout from the origin for the benefit of having all datasources in the clone's layout pointing at the local items thanks to SCORE's smart copy/clone/duplicate feature
3. Don't use page local datasources on the items you intend on cloning to make it clear that modifications on the origin and the clone are funneled to the same site global content items.
4. Don't use datasource-driven renderings on the items you intend on cloning to more clearly separate presentation details from the content