TLDR; This is a Public Service Announcement to all Adobe Experience Manager users: don’t just delete content from the Author instance. Make sure you deactivate/unpublish it first.
When I first started working with Adobe Experience Manager, I frequently made the mistake of just deleting a page or asset or tag. Deleting just makes everything go away, right? Wrong! I would then have to go to a developer or server admin when I couldn’t figure out why my piece of content was still on the Dispatcher end of the site. After a while, we figured out that the problem came when I would delete something that had been activated. I needed to deactivate the content first, and then I could delete it.
The reason for this is because of the structure of the servers in Adobe Experience Manager. You have an Author server that sends data, ready for the live site, up to a Publish server. The Publish server then serves it up through the Dispatcher. Deactivating something will remove it from the Publish server. It helps to understand that the Publish server only holds those things (pieces of content/assets) that belong on the live site. They are not the staging area for your content; that’s what the Author server does. Publish only wants to hold those things that a front-end user should be able to access. Deactivation is deletion for the Publish server.
Some people have said that if I hit delete then it should deactivate it for me and then remove it from the Publish server. It’s hard to argue against this. I struggle to come up with a legitimate reason to argue for this “feature”. I’m not even going to waste time trying to be the apologist and come up with a legitimate reason for this. Quite simply, it’s bad. Hopefully this will be something that Adobe fixes in future releases. As of Adobe Experience Manager 6.1, it is still an issue.
A Workaround
Ok, so what happens if you get stuck and you don’t have access to the Publish server (most of the time your Publish instance should be locked down anyway)? And let’s assume that this isn’t the first time that this has happened and you don’t want to go talk to the server admin who controls the Publish instance. In our scenario, you have just deleted a page that had previously been activated. A solution is to create a new page on Author with the same name. Then activate/publish it. And lastly, deactivate/unpublish it. Viola, your orphaned page is removed from the Publish server. What happens is that the Publish server looks at the node name and at the node type that is requested to be deactivated. So, if it matches, then it will be removed. This only works if you know what the exact name and type (asset or page type) was. It doesn’t really care about anything else. What is happening here is that you are trying to reconnect the communication between Author and Publish because the deletion severed that connection. Truthfully, I would just bite the bullet and go talk to the server admin.
It’s annoying that this is the procedure that has to be used. But in honesty, I learned about it and now it is part of my normal routine, and I make sure it is part of my customer’s routine too. I know better than to make this mistake anymore. So, let this be your mantra when working with content authors: Deactivate and THEN Delete. And since the name changed in the Touch UI, Unpublish and then Delete. Annoying, yes, but a much better option than having to get a server admin or a developer to go into the Publish instance to remove your piece of content. If you know of any other Adobe Experience Manager gotchas then drop us an email: info@aempodcast.com.