Skip to main content

Advanced Item Cloning

Cloning in Sitecore can be extremely useful. It makes reusing of content items and updating of those items very easy. The default capabilities for item cloning can usually handle most needs. The default behavior does have one thing that can really trip you up. By default clone, child items stay linked to the source cloned item and are not reparented to their new cloned parent. The first thing to understand is there are configuration options for cloning that allow you to change how cloning works. The configuration files have them pretty well documented but if you don't know what you are looking for you may not know they are there.

  1. <setting name="ItemCloning.Enabled" value="true"/>
    1. Specifies whether the Item Cloning feature is enabled
    2. Default value on CM and Standalone servers: true.
    3. Default value on CD, Processing and Reporting servers: false.
  2. <setting name="ItemCloning.NonInheritedFields" value=""/>
    1. Specifies a pipe-separated list of field names or field IDs which should be not be inherited by clones from their source item, in addition to the following fields from the standard template that are never be inherited: 
      1. Updated, Updated by, Revision, Created, Created by, Source, Workflow, Workflow State, Lock
  3. <setting name="ItemCloning.InheritWorkflowData" value="false"/>
    1. Specify whether you want the workflow and workflow state fields to be inherited by clones from their source item. Note: When you change the setting value, clones move in or out the workflow, which may affect their behavior, for example, on publishing.
    2. Default value: false
  4. <setting name="ItemCloning.ForceUpdate" value="true" patch:source="ClientContent.config"/>
    1. Specify whether clones should be updated automatically when:
      1. A new version is added to the original item.
      2. A new language is added to the original item.
      3. A new sub-item is added to the original item.
      4. Note: If true, all the clones of the original item are updated automatically.
      5. Default value: false
  5. <setting name="ItemCloning.DeleteClonesWithOriginalItem" value="false"/>
    1. Specifies whether item clones should be deleted when the original item is deleted.
    2. If true, when the original item is deleted all its clones are deleted and not just uncloned.
    3. Default value: false
  6. <setting name="ItemCloning.ForceUpdate.ChangeTemplate" value="false"/>
    1. Specify whether clones should be updated automatically when a different template is selected for the original item. Note: If true, all the clones of the original item are updated automatically.
    2. Default value: false
  7. <setting name="ItemCloning.RelinkClonedSubtree" value="true" patch:source="ClientContent.config"/>
    1. Indicates that after cloning an item tree structure, all the internal links inside the cloned structure should be re-linked to point to the items in the cloned sub-tree. 
    2. When the setting value is false, the links in the cloned structure will still link to the items in the original structure.
    3. Default value: false
We need to go a little deeper on the last one (RelinkClonedSubtree). The reason for this is it only "kind of works". It works when the tree you are cloning is shallow. 

What happens when we do a deeper clone though of a folder and subfolders? The process to relink items is triggered via the "uiCloneItems" pipeline. In that pipeline is this processor "<processor type="Sitecore.Shell.Framework.Pipelines.CloneItems,Sitecore.Kernel" method="RelinkClonedSubtree" mode="on"/>". This code is only responsible for seeing if the setting for this is true and if so triggers another pipeline. 

public void RelinkClonedSubtree(CopyItemsArgs args)
      Assert.ArgumentNotNull((object) args, nameof (args));
      Assert.IsNotNull((object) args.Parameters, "parameters");
      if (!Settings.RelinkClonedSubtree)
      Item[] copies = args.Copies;
      Assert.IsNotNull((object) copies, "copies");
      foreach (Item obj1 in copies)
        if (obj1.SourceUri != (ItemUri) null)
          Item obj2 = Database.GetItem(obj1.SourceUri);
          if (obj2 != null)
            CorePipeline.Run("replaceItemReferences", (PipelineArgs) new ReplaceItemReferencesArgs()
              SourceItem = obj2,
              CopyItem = obj1,
              Deep = true,
              Async = false

The "replaceItemReferecnes" only has one processor of "<processor type="Sitecore.Pipelines.ReplaceItemReferences.StartJob, Sitecore.Kernel"/>" and all that processor does it create and trigger an instance of "ReferenceReplacementJob". 

Long story short here there are two main issues here. First, there is currently a bug in this functionality as of Sitecore 9.3 where trees with bucketable items don't work when cloning a deep tree. Sitecore support has a bug on this you can reference with number 370689. But if you enable this RelinkClonedSubtree configuration setting the new cloned subtree items will reference the clone parent items instead of the original item it was linked to. For me it feels like this should be the default behavior but at least there is an options to make this work. 


Lia S said…
Great reaad thankyou

Popular posts from this blog

Excel XIRR and C#

I have spend that last couple days trying to figure out how to run and Excel XIRR function in a C# application. This process has been more painful that I thought it would have been when started. To save others (or myself the pain in the future if I have to do it again) I thought I would right a post about this (as post about XIRR in C# have been hard to come by). Lets start with the easy part first. In order to make this call you need to use the Microsoft.Office.Interop.Excel dll. When you use this dll take note of what version of the dll you are using. If you are using a version less then 12 (at the time of this writing 12 was the highest version) you will not have an XIRR function call. This does not mean you cannot still do XIRR though. As of version 12 (a.k.a Office 2007) the XIRR function is a built in function to Excel. Prior version need an add-in to use this function. Even if you have version 12 of the interop though it does not mean you will be able to use the function. The

Experience Profile Anonymous, Unknown and Known contacts

When you first get started with Sitecore's experience profile the reporting for contacts can cause a little confusion. There are 3 terms that are thrown around, 1) Anonymous 2) Unknown 3) Known. When you read the docs they can bleed into each other a little. First, have a read through the Sitecore tracking documentation to get a feel for what Sitecore is trying to do. There are a couple key things here to first understand: Unless you call " IdentifyAs() " for request the contact is always anonymous.  Tracking of anonymous contacts is off by default.  Even if you call "IdentifyAs()" if you don't set facet values for the contact (like first name and email) the contact will still show up in your experience profile as "unknown" (because it has no facet data to display).  Enabled Anonymous contacts Notice in the picture I have two contacts marked in a red box. Those are my "known" contacts that I called "IdentifyAs"

Uniting Testing Expression Predicate with Moq

I recently was setting up a repository in a project with an interface on all repositories that took a predicate. As part of this I needed to mock out this call so I could unit test my code. The vast majority of samples out there for mocking an expression predicate just is It.IsAny<> which is not very helpful as it does not test anything other then verify it got a predicate. What if you actually want to test that you got a certain predicate though? It is actually pretty easy to do but not very straight forward. Here is what you do for the It.IsAny<> approach in case someone is looking for that. this .bindingRepository.Setup(c => c.Get(It.IsAny<Expression<Func<UserBinding, bool >>>())) .Returns( new List<UserBinding>() { defaultBinding }.AsQueryable()); This example just says to always return a collection of UserBindings that contain “defaultBinding” (which is an object I setup previously). Here is what it looks like when you want to pass in an exp

WPF Localization - RESX Option

About a year ago I was building a WPF project in .Net 3.0 and Visual Studio 2005. I wanted to revisit this subject and see what has changed in .Net 3.5 and Visual Studio 2008. I will make a few of these posts to try and cover all the different options (RESX option, LocBaml option, Resource Dictionary Option). In this blog I will focus on using a resx file to localize an application. To show how the resx option is done I created a WPF form with three labels on it. The first label has is text set inline in XAML, the second has it text set via code behind from the resx file and the third has its text set via XAML accessing the resx file. The first thing that needs to happen to setup a project for localization is a small change to the project file. To make this change you will need to open the project file in notepad (or some other generic editor). In the first PropertyGroup section you need to add the follow XML node <UICulture>en-US</UICulture>. So the project file node w