Replication for Deleting or Moving Files or Folders - Standard Practices in AEM

[mcherun]

I’m a Web Designer with a content administration role for our AEM product. I don’t have full access to the back-end and admittedly I am not a strong developer but I’ve used enough Content Management Systems to get a sense of ‘normal’ user experience of site administration expectation. Something about our current setup for replication doesn’t make sense.

Our AEM has been configured by a third party in such a way that whenever you delete an asset from the author mode (non-published), it does not get moved nor deleted from the live (published) site.

Similarly, if you Move a folder or files, the old files don’t get ‘moved’ on the live site, it seems they get copied instead to the new folder.

This results in many duplicate files remaining on the live server that we can’t easily delete because there is no record of them on the author server. I can use lists and searches to find them and track their path and submit them to another team who has access to the live site to delete).

I’ve been instructed that in order to delete or move a folder or file, we must first deactivate it, and then wait for the queue to update so that it’s actually deactivated before deleting or moving the file or folder in the DAM.

In my mind, this seems to be a work-around approach, as why would Adobe include a Move or Delete feature if the standard best practice is to deactivate first.

Can you clarify if this is a ‘normal’ expectation of deployment / replication standard practice? Can you point me to any supporting documentation or web site information?

[Andras_Fejer]

I tried to move files and folder in the Asset administration view (Classic UI: http://localhost:4502/damadmin) on a default AEM 6.0 instance and all action got automatically replicated to the publish instance. Even the resource references on pages got automatically updated. The only case where I had a duplicate folder was, when I moved a folder which contained an activated image, but the folder itself was not activated.

It's hard to tell why in your case DAM actions aren't replicated properly to the publish instance. Could it be that a workflow got changed which might cause the described effect?

The workflows can be found here (if you have the correct rights): http://localhost:4502/libs/cq/workflow/content/console.html

[Lokesh_Shivalingaiah]

You might be using some custom workflow !! but OOB it should work...

[mcherun · Accepted solution]

This was resolved, yes it was a faulty workflow and our 3rd party implimenters resolved it. It confirmed my suspicions that deactivating before moving or deleting files to avoid ghost files was not standard functionality.

RESOLVED!