Expand my Community achievements bar.

SOLVED

AEM 6.4 - RolloutConfig with "modification" triggered deletion of pages doesn't work if there is a separate ad-hoc Live Copy

Avatar

Level 4

Hello everybody!

The problem we faced is that when you use rollout config with the "modification" cq:trigger, for example, default "Push On Modify", delete page action stops working correctly when you create Live Copy of a master page. It stops producing "contentDelete" LiveSync action (page event) and does not roll out anything if there is at least one separate ad-hoc Live Copy page of this changed blueprint page.

It behaves the same for default We-Retail installation. You can test it with the default "Push On Modify" Rollout Config or create a new one with cq:trigger="modification" and "contentDelete" LiveSync action.

Actually, we use "modification" -> "contentDelete", because we need to delete all Live Copy pages after a blueprint page was removed.

Automatical removing (rolling out) of live copies with such config works until you click on a master page and use "Create" -> "Live Copy" button. Then it stopped working and didn't work even if you remove that newly created live copy page.

Log output is: "MSM does only deal with Blueprint Resource /path/to/my/page/resource: ignore". But the resource was actually a blueprint !!!

This functionality worked perfectly in AEM 6.2 and stopped working after it was upgraded to 6.4.

Removing of pages using "Standard Rollout Config" and "Rollout with children" button is working, but we can't use it because we have a huge lot of pages.

I tried to debug the process and found out that after you create ad-hoc Live Copy, event processed by MSMEventProcessor class contains a path with a changed (deleted) page, and this change is already saved into a repository (if there are no ad-hoc live copies, the event points to an existing resource). And it stays the same even if you delete those live copies. But, if you delete Live Copy and then restart AEM, the rollout configuration starts working, event resource becomes existing then there.

Does somebody know which way it can be fixed or what we can use instead of these rollout configs for deleting pages in 6.4?

(Updated. Other LiveSync actions except deletion should work because resource exists there).
Message was edited by: Yuriy Shestakov

1 Accepted Solution

Avatar

Correct answer by
Level 4

Daycare accepted this behavior as somehow unexpected and answered that this problem can be a result of already known AEM bug CQ-4258705, waiting for fixing it.

View solution in original post

7 Replies

Avatar

Community Advisor

Hey Juriy,

Does data saved under JCR via dialog is saved in correct order?

Regards,

Peter

Avatar

Level 4

When we tested default "Push on Modify" - we didn't change anything in it,

when we created our new one, we used just one element - "contentDelete".

So, the order doesn't matter.

Or are you saying about other elements? Please clarify, what order do you mean?

Avatar

Community Advisor

Hi Juriy,

OK, if the order does not matter and it worked in 6.2 sounds like a DayCare ticket to me.

Regards,

Peter

Avatar

Level 4

They said if we use "modification" trigger, the result of the action is not determined. So, they suggested not using it. Don't know what to do.

And nothing like this noticed in the official documentation 

Avatar

Community Advisor

Hi Yuriy,

Trying to help you further here,

Is it possible to ask you to create a test project with default content that could be installed on any 6.4 machine and would clearly indicate a problem?

Regards,

Peter

Avatar

Level 4

Ok, here is a copy from my DayCare ticket. Here I am using "Publish on Modify" rollout config, but, as I said previously, you can create your own or delete all actions from this config (leave only contentDelete) - and it will work the same.

Hope it will help you reproduce it.

Upd: It is not like test content, but you can reproduce the problem using AEM OOB installed with sample content, so don't need any custom package.

Avatar

Correct answer by
Level 4

Daycare accepted this behavior as somehow unexpected and answered that this problem can be a result of already known AEM bug CQ-4258705, waiting for fixing it.