We are migrating from AEM 6.1 to 6.5. So the authoring for existing pages is done in classic UI.
Here there are few config pages where the content is referred across the sites.
The config pages have multifield components in it. When the authoring was done in classic ui for the multi field values where re-ordering of fields have taken place, the node names were not saved in order.
for ex: when i initially save the dialog, the nodes would save as item0,item1 ,item2. When i again open the dialog in classic ui and re-order the multifields, the nodes would save as item0,item2 and item1.
So this is the case for all the existing pages. The pages referring the values from these config pages are done via the nodes name.
Now if I open the dialog in touch UI and save the dialog without any changes, the nodes will be saved as item0,item1,item2.
So if a page is referring item2 of config page would now refer a different node after dialog saved in touch ui.
Is there any way to handle this usecase. Any suggestions are welcomed.
Is there a way to stop renaming the nodes after dialog save in touch ui? As even in 6.5 classic ui the node names are not changing after re-arranging the multi filed values.
First of all the logic to read the node by its name, itself is not recommended always go by the resource type or childResource iteration to get the nodes and use it wherever needed. you will face lots of issue like that with the current approach.
In touch UI this is the desired behaviour, that you mentioned so I don't think so there will be anything, that will come into rescue. So better to change the logic as a permanent fix.
Depending on the extent of what needs to be updated, try writing a utility servlet that 1) reads your 6.1 ordered nodes into an array - item0, item2, item1. 2) deletes the nodes in the repository then 3) reads the nodes from the array and saves them back to the repository as item0, item1, item2. You could accept parameters such as page name, resourceType, node name to have some control over what's getting updated. You would run this once to prep your data for the 6.5 migration