This looks to be a new way of how tags are managed in v6.5.x, but i'm trying to understand the reasoning behind it. My use case is all the taxonomy is getting updated in the project, which means tags are moved to different folders, new folders are added etc, which all depend on the OOTB Move operation, and if I use OOTB move operation, I will end up having the legacy tag structure in AEM (seen only in crx/de) and a mapping which will point to old paths. This creates a lot of dependency with the old tags, the path and the 'hidden' tags, and i'm concerned if this will have any impact in the future, if taxonomy is again updated or possible future upgrades.
So, i'm planning of developing a utility to custom move the tags and also update the references in crx/de and not end up having any legacy tag paths and hidden tags. Is there any reason why I should not do this? And is the v6.5.3 tagging move behavior a product bug or is that how it's intended to work, which is little weird isn't it?
Solved! Go to Solution.
Hey,
I hope you have reviewed the official doc [1] which has details on explanation on cq:movedTo and cq:backlinks properties.
Reards,
Vishu
Hey,
I hope you have reviewed the official doc [1] which has details on explanation on cq:movedTo and cq:backlinks properties.
Reards,
Vishu
hi,
it is ok to update the tag path using the custom utility.
Hi Berus,
I have a similar requirement > where I want to display the tags from new location after move. Do you have more details about the utility?
Did you get a DM response
I am looking at the same challenge here and i am not certain that this cq:movedTo is what is needed to clean up the tagging structure. Here there is a additional problem with Brand Portal publishing of those old tags. I can not unpublish the tags as long as the value is hidden in AEM, i can not recreate them visible to depublish them, since the old tag is still there.
Views
Replies
Total Likes
Views
Likes
Replies