Referring to my earlier post – Restructuring-the-tridion-blueprinting-and-content-demotion – another issue while doing demote is that you might still have a handful of items which could not be demoted citing he variety of dependency they may have. Few examples of such dependencies are:

1. Item is checked out
2. Referenced in another item which will be in a publication which have no relationship with the target demote publication
3. Item is published from a publication  which will not be a child of the target demote publication
4. The item is added into a bundle
5. A cyclic reference to items with in the same publication from you are trying to demote
6. The items are localized in a publication which is up in the blueprinting hierarchy than the target demote publication

While most of these demote blockers requires to be resolved manually, to aid the process of identifying the unresolved dependencies, we at Content Bloom created a core service script which essentially extends the “Where Used” feature to provide a detailed matrix of all items with in a folder on a single html page or as a JSON (so as to enable further custom processing if needed)

As a third step (refer the above referenced post and This Post  and This Post if you need a background of this series of blog) if there are unresolved dependencies remains in this massive demote exercise, we execute this script to get a report of all unresolved dependencies for the items which fails to demote.

This script, requested for the folder TCM URI, processes each items inside the folder recursively, and generates a json of all dependencies of each item viz. where used, what it uses, where localized, where published, whether checked out etc.

Another small program accepts this json to convert it into the HTML format for better visualization.

This table can  be used to identify the dependency, enables to resolve those dependencies manually, or take corrective actions for demote operation.

The below screenshots will explain it a bit better:

The recent improvements(DXA, Headless etc.), content modeling demands, and more aggressive content changes requirements; triggers a change in existing Tridion blueprinting hierarchy from the traditional, wide, isolated architecture to a lean, interchangeable, and less site/publication dependent.

After completing two such blueprinting transformation, we come across a bit next level changes – which clearly looks looks implemented earlier without any brain storm – Every content was created in 020 Global Master for all websites/verticals where not a single content is shared across the websites/vertical – This creates a huge confusion for content author as well as quite error prone for content authors (mostly System Admins) who ended up updating a wrong content breaking functionalities on another site unexpectedly.

A solution was proposed to minimize the number of publications by reducing the various levels of publication vertically and expanding it horizontally by demoting the content from 020 Global Master to individual Site Masters.

The main challenge in this task is doing a massive number of demote of already published components and categories as well as a number of localized version of items in child publications.

Moreover, since there is a hierarchy of folders, we can not simply choose the root folder and start demoting as the demote has to be start from the leaf of content tree – so apparently, have to traverse all folders and demote them individually – a big limitation of existing demote process. Refer the below capture from  SDL Tridion Docs:

Following are few learning we have while performing this big overhaul of Content restructuring and appropriate measures must have been consider while doing demote:

1. Whenever demoting the content – the custom permissions and security applied will be vanished and only inherited permissions will be applied.
2. Demoting the content will delete all previous/old version of the item
3. The demote of an item will not work if:
   • It has been published from a publication which is not a child of the publication to which the content is demoted
   • It has been in use in any way (component link, RTF field link etc.) by another item in a publication which is not a child of the publication to which the content is demoted
   • It has been localized in a publication which is up in blueprinting hierarchy from the publication to which the content is demoted
   • The item is checked-out
4. You can not choose folder to demote all its content
5. Despite of all measures, there are good chance of scenario which restrict the demotion process – for example: cyclic reference of components through component link

I will be discussing in subsequent post about how we dealt with above scenario to have a rather smooth demotion of huge number of Tridion items for multiple websites without a zero down time. Stay Tuned!