Expand my Community achievements bar.

SOLVED

live copy issue when we hit the detach option

Avatar

Level 1

Dear All,

 

In the production environment livecopy page, the user hits the “detach” button without knowing the risk,  We tried many ways to get it back but we are unable to rollback it again because Detach option permanently removes the live relationship between a live copy and its source(blueprint) page.  (we tested in my local environment)

 

dinesha35459980_0-1620736090438.jpeg

 

 

Would you please help us is there any way to  get the same live copy page back? And also please help us on  below scenario.

 

 

Even after detach the live copy relationship, we can see blueprint (ex: /content/we-retail/language-masters/en/men ) option, and we did rollout for below men page (we already detached the live copy for men page)

 

dinesha35459980_1-1620736090449.jpeg

 

 

 

we can see the "men_msm_moved" is created when the a rollout action is triggered and it doesn't have the any live copy relationship and content is being rolled out to a livecopy where an identically named resource is located (us/en/men).

 

 

 

dinesha35459980_2-1620736090458.jpeg

 

 

Men page:-  (live copy has been created )

 

dinesha35459980_3-1620736090461.jpeg

 

 

MSM_MOVED_Men page:-  (no livecopy relation)

 

dinesha35459980_4-1620736090467.jpeg

 

Now we need to move the content from us/en/men_msm_moved to us/en/men. Because all old content (parent page content along with used added extra content) is available in us/en/men_msm_moved and live copy relation is with us/en/men page.

 

Would you please help on this?

 

Many thanks.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi @dinesha35459980 ,

 

Unfortunately, detach action is permanent and non-reverisble.

Detach option permanently removes the live relationship between a live copy and its source/blueprint page. All MSM-relevant properties are removed from the live copy and the live copy pages become a standalone copy.

 

It is clearly mentioned in the documentaion.

https://experienceleague.adobe.com/docs/experience-manager-65/administering/introduction/msm-livecop...

 

You need to recreate the live relationship.

View solution in original post

2 Replies

Avatar

Correct answer by
Community Advisor

Hi @dinesha35459980 ,

 

Unfortunately, detach action is permanent and non-reverisble.

Detach option permanently removes the live relationship between a live copy and its source/blueprint page. All MSM-relevant properties are removed from the live copy and the live copy pages become a standalone copy.

 

It is clearly mentioned in the documentaion.

https://experienceleague.adobe.com/docs/experience-manager-65/administering/introduction/msm-livecop...

 

You need to recreate the live relationship.

Avatar

Community Advisor

Hi @dinesha35459980,

When a sub page is detached from the relationship, mixin related to LiveRelationship on that would be removed. However live relationship with the parent is still retained (as the relationship is not detached at the parent level. Instead from the sub page level alone.)

With this, next time when you trigger a rollout from language master, it tries to create a live copy - in this case, the page name is men. When it gets to see the page with same name already existing, It then renames it to msm_moved (nodes with same name can't exist in the same hierarchy) and creates a actual live copy as available in master as men.

 

Now to bring back the content as available in old men.html/msm_moved page, one of the ways that you can try

  • Create a Page version of Language master/men.html
  • Author the additional changes as available in msm_moved in language master 
  • Trigger a rollout -> will update the live copy/men.html
  • Create a Page version of Language master/men.html (optional)
  • Revert language master to Page version as created in Step 1 (so that no other live copies of this language master is impacted with us/en specific content)
  • Once when live copy men.html is up to date with latest content, we are good to purge the msm_moved pages. (Take a content back up of msm-moved filters for safer side before you purge)

If the above approach is not suitable, suggest to share the details of your old content as mentioned in the post - "Because all old content (parent page content along with used added extra content) is available in us/en/men_msm_moved "