Oftentimes in my work with clients, we are asked a lot about shortcuts or ways to quickly and easily re-create content pages from their website that have complex layouts or are very labor-intensive. We discussed in a previous blog post how copying is not always the best answer. In this blog post, we’ll review why cloning might not be the same kind of shortcut you are looking for either.
When cloning is good
When you clone a page, Sitecore makes a copy of the original page and uses the data items from the original page as content. Any changes you make to the original will ripple outward and be applied to the clone. This works great for pages with a simple layout that need to be replicated on another brand, microsite or version of your site, like a blog post, article or even a product page. Cloning gives you the ability to maintain several copies of a site, where you’d only need to update the content on the original and all the clones will get the same exact changes applied.
When cloning is troublesome
The key to cloning being useful is that the cloned pages are simple. For pages with multiple components or other moving parts, cloning starts to get troublesome. Content authors that I’ve worked with that use clones cite the importance of needing to maintain page and field inheritance (aka. the link between the original item and the clone) but run into difficulties when they come across pages or content that “just need this one small thing to be different from the other page”. Versions can also be prickly to work with. Sitecore’s warning and error message notifications when they try to update a page can be confusing, and less experienced authors may accidentally break that link between the original and the clone. While it is easier to restore and resync an individual field between an original and a clone by resetting the field value, an un-cloned page can never go back to its cloned state. You need to delete the un-cloned page and create a new clone from the original.
Workflow states can also create issues. If you clone an original in the middle of its workflow, the clone will inherit the same workflow state, but will not maintain a connection. So, as your original finishes out its workflow and gets published, the workflow of the clone will remain in the same state it was created and would also need to be moved through to publish.
So, where does that leave us?
Outside of specific use cases, cloning is not going to be the shortcut you’re looking for if you’re trying to quickly create complex pages. A better way would involve working with your development team to create a branch template that includes a base set of components already placed into the layout for your page. Authors will still need to move in your content and might need to add some additional components to a page, but it goes a lot faster than starting from a completely blank layout.
Hey – This is a good article. Nice to know about the drawbacks of cloning pages in sitecore. Very well written. Thanks for sharing.