I’m looking at using the new cloning functionality of Sitecore 6.4 to help with reuse of components and content for a multiple site, multiple language solution.
The basic idea is to create a central content repository within Sitecore (possibly in multiple languages) which could then be cloned to provide regional sites, each with their own selection of supported languages. The thinking behind this is to allow regions to easily replicate the content they require and take ownership of it. With cloning they would be able to edit the data where they required without affecting the source data, choose to leave out items which were irrelevant to them (e.g. where a product wasn’t available in their country), add new content that was entirely specific to their country and translate into any regional dialects they wished to support (e.g. Swiss French: fr-CH) etc.
The core set of sites will share a large proportion of thier source data, though with most language versioning occuring locally.
Has anyone got any experience with this sort of Sitecore deployment? What are the pitfalls?
Once this structure was established, however, the open-endedness scenario enters play. New sites, e.g. a product launch splash site, might be added to the Sitecore instance, and we would expect these to share content, templates, presentation etc where appropiate (though to a far lesser degree than the core sites).
While cloning allows replication of content with the possibility of modifying that content in its local instance I’m trying to find a way to allow a similar procedure for templates. Is it possible to use the base template feature of template inheritance to creat a layer of “abstract” templates, which would be instantiated in concrete templates used to create items? Again, the idea here would be to allow local flexibility while sharing core functionality. Our aim would be to keep a clean set of abstract templates and only introduce modifications in locally instantiated versions of them. If all templates deriving from an abstract template required a new field then this could be added at the abstract level.
We hope to stay withing Sitecore out of the box functionality as far as possible.
Is this approach at all workable, or have I mixed my paradigms? What considerations should I have while we’re still very much in pre-design phase? What sort of design-rules do I need to establish for developers?
Answering my own question, with credit to John for some pointers.
After some research, and the helpful comments left on the SDN forum, it seems this approach is largely workable.
With clones it is possible to create a central data repository, rather than physically replicating the data to the sites that will share it. It is also possible to overwrite data in a clone in order to provide local specific content. This can be done on a field by field level, so that one field of a cloned item remains inherited from its parent while another is specific to the site in which the clone appears.
This will allow local sites to replicate the structure and layout of the default site while maintaining flexibility over their own content requirements. This can also be achieved across multiple languages.
UPDATE: One major problem not addressed is how to handle internal links that will be formatted to URLs. If a link is included in a rich text field, for example, it will reference a GUID of an item. When cloned this GUID will be the same, even though it points back to the parent structure, not to the clone structure. Editing the link will break the clone reference for that field, so updates to the parent item won’t be pushed through to the clone. There is no simple workaround for this problem, though it could be possible to extend the LinkManager to lookup a clone reference instead of merely producing the URL. This is a significant drawback, possibly even a showstopper.
There doesn’t seem to be any simple way of implementing true abstract templates (i.e. no cloning method as for items) but it would be possible to provide a halfway solution based on a clean set of base templates that could be inherited by local versions. The main problem with this would be that cloned items would automatically be associated with the templates their parents were created from, rather than a local version. Changing cloned item templates to a local version would be possible (even automatable provided we were happy with customising the Sitecore cloning procedure). Without automation this would inevitably lead to increased maintenance of the sites and the possibility of user error. As the local templates would still inherit from the base “abstract” templates we would be able to implement changes to all sites by altering the abstract template.
A further challenge for such an architecture is to ensure that all item references are relative, so that a link to Products on each site will lead to that sites Products, rather than the Products data set in the central repository. Design guidelines for developers will include a requirement that all paths to data sources are directly configurable from within Sitecore (such as by using the data source field of a rendering).
As the cloning feature is still relatively new it doesn’t seem like there is much experience with it as yet. This type of data re-use is, however, the reason cloning was added to Sitecore.
The main pitfall of such an approach appears to be the requirement to fully assess the impact of design on varying local sites, leading to increased complexity of development and code maintenance.