Fulfill Preconditions

Before you apply the hierarchy change, make sure you have fulfilled all preconditions mentioned in Section 4.7, “Preconditions for Comprehensive Changes”.

For the following steps, it is important that you have read section 4.9.2 to learn about the general concept of moving sites within the site hierarchy.

Overview of the steps to apply the new hierarchy along with a short excerpt:

And eventually: Done: Final Remarks .

Must not Use CoreMedia Studio

An endeavor like this must not be done in CoreMedia Studio. It is not only, that the complexity of this task is too high, to keep track of all required adaptations, but also, that CoreMedia Studio makes some assumptions on normal editorial work, that will collide with the required adaptations during this process.

Also, any automated process will help to evaluate the process on test systems before applying it to the production system.

en-IE: Create Translation Settings

As described in Section 4.8.1, “The Site Type” the site type is stored in a settings document at Options/​Settings/​Translation. In a typical setup, it is just the root-master site that does not have a translation settings document. Thus, at some point in time you need to decide on the site type for the site en-IE now that it becomes a derived site. Doing so now, at the very beginning, will help restructuring your site, as it helps to find required related variants of these settings to adjust across all sites.

To create this (yet) artificial settings document, follow these steps:

en-FR, en-DE: Move Child Sites

Move the child sites en-FR and en-DE to below the site en-GB. This will make the site en-GB the new master site. The sites can be moved one by one.

You can use the Sites Service and the corresponding ContentSiteAspect to determine, which contents between the sites are related to find the new master link to set.

As a result, the site hierarchy will look like this:

Handle Nested Derived Sites Later.  You will notice, that the nested derived sites (like fr-FR) will now be marked as outdated. This is due to the fact, that their respective master content items got updated regarding their properties for master and master version. As more changes will be applied next, there is no need to repair this state now. It will be done later.

en-IE, en-GB: Flip Roles

In this step, we have to touch two sites in parallel, thus, en-GB and en-IE. While the general process is similar as described in Section “ en-FR, en-DE: Move Child Sites ” and the general pattern to apply in Section 4.9.2, “Moving Sites – General Concept”, there is one highly recommended difference to make, which is to prevent intermediate cycles especially in the site hierarchy.

To do so, the recommended order of steps is:

As described in Section 4.9.2, “Moving Sites – General Concept” it is recommended to process the site indicator document as the last document as you are able to process all other documents in the site one by one, still being able to find their related variants. This is especially important for larger sites in terms of documents contained.

As a result, the site hierarchy will look like this:

All Sites: Review/​Set/​Remove Site Type

If you followed Section “ en-IE: Create Translation Settings ” the site en-IE is now a derived site and already has the desired site type set.

It is now a good time to review the site types of en-FR and en-DE. In the new structure, you may want to decide differently, like while they may have been translation sites before, they now may be better off as synchronization sites. For details, read Section 4.8, “Changing the Site Type”. The preconditions should already be fulfilled (like all workflows stopped and content items were up-to-date before the change), but you may want to check them again.

Remove Site Type for en-GB .  As en-GB is now a root-master site, the site type setting is not needed and should be removed. Ensure, to remove master links towards that document before doing so.

en-GB: Cleanup (Optional)

If not done before clean up the site en-GB by removing the master-versions of the content items as well as unsetting any possibly set ignoreUpdates flag. The latter must be done via the Unified API, as the setting is not visible in the CoreMedia Studio user interface for root-master sites.

This step is purely optional, as the master-versions and states of ignoreUpdates are not relevant for root-master sites. Still, they may cause issues in subsequent editorial work, like when such contents get copied to other sites (rather than using the recommended workflow based propagation across sites).

All Sites: Up-to-Date

Now you benefit from the precondition, that all content items were marked as up-to-date. You just restore this all up-to-date state by updating the master versions of the content items in the derived sites accordingly.

Note the order of doing so: Starting from root-master site en-GB (where no master versions need to be updated), first visit all directly derived sites, and then all nested derived sites as each update to the master version also creates a new version of the document.

Validate Your Multi-Site State

As the previous steps may have introduced issues, it is recommended to validate the multi-site state. This can be done with the command line tool cm validate-multisite as described in Section 3.13.1.11, “Validate Multi-Site” in Content Server Manual.

An excerpt of possible new issues after restructuring are (you will find a description along with the command):

Find possible countermeasures in the description of the command as well as in this manual.

Publish New Hierarchy

While restructuring your site hierarchy most likely is dedicated to changed editorial requirements, you may want to consider publishing the changes to the live system now or near-term. Due to the most likely high amount of contents changed, you may want to consider a staged rollout.

How to stage the rollout should be planned as carefully as the internal changes to the site hierarchy. Assuming that it is ok to risk temporarily unavailable possibilities to switch between language variants in your deployed site, this publication order (per site) may be one possible option:

This prevents the risk of introducing a cyclic master-derived relationship, which may happen if the site en-IE is published first. Just as described in Section 4.9.2, “Moving Sites – General Concept” it may be beneficial to process the site indicator document as the last document to be published for each site.

Thus, it makes sense, to carefully think about the publication order in similar small steps and intermediate states as sketched here.

Done: Final Remarks

During the transformation you will create mildly irregular states (such as the link to the root-document not being updated for the temporary site). These irregular states are now gone, so that your editors may start working again with the new site hierarchy. Your editors should be aware though, that updates to the translation state in CoreMedia Studio will take some time to be fully propagated, which means, for example, that library filters may not provide the expected results until these updates have been propagated.