Using Adobe Experience Manager Versioning for Common Problems

[#1]

Author: Aditya Sharma

First, a little about myself. I am a newbie into the world of Adobe Experience Manager (AEM), and I am blogging about the problems that I faced during my AEM development process. Here are some of the solutions I’ve jotted down along the way, after a lot of digging around and troubleshooting.

If you are looking for the official, exact know-how on implementing AEM versioning then I suppose this would be the link to check out. But, in case you are looking for answers to the more practical problems that we see in our day-to-day life with AEM—some of which can be relieved using the versioning mechanism—then read on.

Let’s begin our fun ride through a few of the problems that we encounter, and how AEM versioning can remedy those for us. Here’s the first scenario:

1. You are an author working on a page, but you have multiple other authors who are trying to make changes to the same page. At times this makes you lose changes you’ve made.

To answer this, we have a page lock functionality available in AEM. Once you use this, the page cannot be edited by anyone other than you. If it’s that simple, you might wonder, what’s the harm in just using this? Nothing. But as soon as you unlock the page, nothing is stopping others from making further changes, and nothing guarantees your changes aren’t lost. Instead, I would suggest using versioning, rather than using the page lock, which makes sense when you are going to work for a long time on the same page or are about to make a lot of changes. But even after that, we should create a version from our page. Why? Because this gives you the option to revert your page to a previous version and retrieve your earlier changes.

Similarly, if everyone maintains their own versions, it becomes easier to revert, compare the various versions, and bring the page back to the state it should be in. You can read more about creating versions in AEM here.

2. A page has been accidentally deleted in AEM. You want to retrieve it, and figure out how it was deleted.

This is one of the more frequent problems, the straightforward answer to which, I could find nowhere. I am speaking from experience. I accidentally deleted one of the pages that was very critical and wanted to bring it back. But since the group I’m working with is not in the habit of creating versions, it’s difficult to do that.

After a lot of troubleshooting to figure out how exactly the page deletion works, I figured out that AEM is “smart” and helps you out. It does not simply go ahead and delete a page; it creates a version out of it before deleting the actual page. In case you want to retrieve it, you can go to the site admin screen and use the Tools options and the restore version option as shown in the screenshot. Select the version for the page deleted and click restore, and voila (!), your page is back. That’s it!

Note that you should be on the path that the page was deleted from before trying to restore it, for the versions to be listed. So, for example, I had a page at the path /content/we-retail/us/en/user/test1, which I deleted; this meant I needed to be on the path siteadmin#/content/we-retail/us/en/user to restore the page before clicking on the restore version option for the pages with available versions listed.

Now that this is sorted, let’s deep dive into how I figured this out.

AEM creates an audit trail for every page in the content root, and as such you should be able to view each manipulation of the page in one place, which is /var/audit/com.day.cq.wcm.core.page. AEM also audits DAM assets and replication, but that is a topic for another time. Now if you check the same path for the page that was deleted here, we would find multiple entries. Each entry shows the operation carried out, the person who did it, and when it was done. If you check this you should see individual entries for each action taken. When we delete a page, we see two entries: one with operation “Version Created” and the other as PageDeleted. If you compare the two timestamps, they are just milliseconds apart. This is how I discovered the AEM auto-versioning feature, and this gives us vital information about which version of the page we would want to restore. See attached screenshot for the Version Created entry.

This screenshot tells us that the page “cq:path property” was versioned and the version ID that was created is 1.0, and hence you would want to version that.

I will conclude this post by saying this is a cool feature to have, and if we use it diligently it would help a lot of heartache when content gets lost!

Until next time, CHEERS and happy versioning!

Originally published: Oct 16, 2019