Hi,
We are facing an issue where when a Language master page is rolled out to the live copy, we see that the order of components in Live copy is different from that of language master and this could be because of the below reason.
Say, along with other components we have a component A in LM and LC (old content before updating/rolling out)and the node name in crxde for this comp is "abc" in both LM and LC.
Now, since the author wants the same comp A again in LM but with a different content, he copy pastes comp A in LM which creates a node name "xyz".
Now since both comps are same with exact same content, he edits the comp which already existed before instead of updating the newly pasted comp. Due to this, the node names would be interchanged now and old comp becomes "xyz" and the new - "abc" ,when its rolled out to LC there is a confusion as to placing the content in LC because here the node name of existing comp A is still "abc" which I think caused the re-ordering of components as contents of these got interchanged.
Do we have a solution to fix such kind of issues?
In this case, shouldn't the "orderChildren" synchronization action take care of this and keep the components' order same as how it is in the LM ?
Views
Replies
Total Likes
@arunpatidar any thoughts on this?
Hi @SHIBANI06
I think, LC does not work like that.
Every node is treated as an individual regardless of type of component.
If there is a common node name then then can be an issue.
Node name are created base don component name(e.g. text) and if already exists then component name and some numbers(e.g. text_1233).
Hi @arunpatidar
Thanks for the response.
yes, that's right but the chances for an exiting node name(say text) to change is only when someone copies and pastes that component again in LM and updates the content of the existing component instead of newly pasted component right(text_123) ? which made existing comp -> text_123 and new comp -> text.
The authors have done some mess up here like I mentioned above and the node name of the existing comp changed in LM, which is why during rollout- the content in LC (which already had 'text' because of previous rollouts) matched with text and the existing comp became text_123. This impacted the order of the components.
So "orderChildren" synchronization action should ideally ignore the components in LC and keep it same as LM right ? This way, re-ordering would not happen? But it is not working for this case.
Hi @SHIBANI06
When you copy the component then it is copied with copy suffix(text_copy).
But I am not sure what can be done here if LC synchronisation changing the order. Better to involve Adobe directly.
Sure
Here are some tips that can help you solve this problem:
Custom Rollout Configurations: Implement custom rollout configurations that explicitly handle the ordering of components based on additional criteria beyond just node names. This can involve scripting or developing custom AEM services that assess other properties of the nodes (such as a custom "order" property) to maintain the correct order during rollouts.
Content Structure Planning: Avoid duplicating components in the same container if their order is critical. Instead, if a component needs to be reused with different content, consider using content fragments or creating a new component that supports multiple instances of similar content within itself.
Consistent Naming Conventions: Establish and maintain consistent naming conventions for nodes. When duplicating components, immediately rename the new node to something meaningful rather than allowing AEM to auto-generate a name. This can help mitigate confusion and maintain a clearer structure in both the Language Master and Live Copies.
Education and Best Practices: Educate content authors about the implications of duplicating components and modifying node names. Encourage them to plan changes keeping in mind the synchronization behavior between Language Masters and Live Copies.
Hi @BrianKasingli ,
Thank you so much for the tips.
I also found that the inheritance of the layout container of the live copy was broken in live copy because of which the re ordering issue occurred when the component was duplicated and edited in LM and then rolled out. I have asked the author to re inherit it back and try rolling out. This should fix the issue.
But they have another concern where they say the order of comps in Language masters is being re ordered when they promote the launch to it.
I believe this also could be for the same reason something to do with authoring from their end.
This flow from launch to Lang Master can also can be customised ?
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies