Hi All,
We have a multi site managed site with around 25 locales. For some specific locales (for eg de_de) we have broken the inheritance and made some changes specific to de language. Now if there is an update language master and then if we roll out it to all language we have to again estabilish the relationship again so that the changes can be rolled out to de_ de as well and then again break the inheritance and make the changes specific to de. In this process content authors are not able to track what were the changes related to de and are missing out on changes. We are looking for some suggestions how this process can be streamlined. Can anybody help us with some insights ?
Solved! Go to Solution.
Views
Replies
Total Likes
Hi @AYU
You should break inheritance not for the whole pages, but for specific properties/components of your page.
The page properties (not the components dialogs' ones) that should have this functionality (inherit / disable inheritance) must have this data attribute:
<granite:data
jcr:primaryType="nt:unstructured"
cq-msm-lockable="yourPropertyName"/>
This way in the page properties on live copies it will be rendered as
So you will be able to click on it and edit and they won't be overwritten during rollout process.
Disabling inheritance of components should work a similar way automatically:
The list of pages that you detached from the blueprints and the list of properties and components for which you disabled inheritance are stored in CRX (cq:LiveSyncConfig etc. nodes on the live copy root). If you configured everything correctly, the rollout process cannot overwrite pages or elements that are in sync (where inheritance is not disabled).
So in your case to do a rollout on already authored pages, you should not detach the whole pages, just go through each live copy page and uncheck that chain button on every component that contains translated text or country/language-specific assets.
To check/manage your live copies connection to their blueprints you can use the blueprints (http://localhost:4502/etc/blueprints.html) interface. The pages where you detached only properties and/or components will look like this one:
There is also OSGI Service, in which you can configure the list of properties that should be ignored during rollout.
Also, you can use content fragments with variations on different languages, or experience fragments with a language-masters tree, maybe it will be better for you to have all that data that you edit often in one place.
Hi @AYU
You should break inheritance not for the whole pages, but for specific properties/components of your page.
The page properties (not the components dialogs' ones) that should have this functionality (inherit / disable inheritance) must have this data attribute:
<granite:data
jcr:primaryType="nt:unstructured"
cq-msm-lockable="yourPropertyName"/>
This way in the page properties on live copies it will be rendered as
So you will be able to click on it and edit and they won't be overwritten during rollout process.
Disabling inheritance of components should work a similar way automatically:
The list of pages that you detached from the blueprints and the list of properties and components for which you disabled inheritance are stored in CRX (cq:LiveSyncConfig etc. nodes on the live copy root). If you configured everything correctly, the rollout process cannot overwrite pages or elements that are in sync (where inheritance is not disabled).
So in your case to do a rollout on already authored pages, you should not detach the whole pages, just go through each live copy page and uncheck that chain button on every component that contains translated text or country/language-specific assets.
To check/manage your live copies connection to their blueprints you can use the blueprints (http://localhost:4502/etc/blueprints.html) interface. The pages where you detached only properties and/or components will look like this one:
There is also OSGI Service, in which you can configure the list of properties that should be ignored during rollout.
Also, you can use content fragments with variations on different languages, or experience fragments with a language-masters tree, maybe it will be better for you to have all that data that you edit often in one place.
Views
Likes
Replies