Skip to main content

Modifying the authoring interface of Adobe Experience Manager – A developer’s guide

Note: Based on AEM 5.6 & above. Requires a developer skill set.
There is a huge outcry in the developer community about the lack of useful documentation supporting customization of AEM’s user interface, one of AEM’s most powerful features. But we get requests from clients all the time who want to customize AEM to add a bit of their own brand and flavor to the out of the box interface in order to facilitate seamless authoring.
After all, no matter how inevitable it is, change can be difficult. This is where CQ (AEM) goes from being a boon to a bane. There is nothing available which defines a clear procedure to customize an existing AEM interface, which is baffling. All that is available to us are bits and pieces of information scattered across a documentation site that resembles a Pandora’s box.
After my repeated struggle in trying to find a correlation between each widget in CQ, I finally gave up this battle and shifted my focus to a more practical approach. So far it has worked well for me. Now I’m going to share it with you.

First, The Fundamental Question

This approach revolves around the basic principles of find and copy, and around the fundamental question: How was the default interface in CQ built?
This led me to a basic “find and modify” exercise, which surprisingly resulted in enabling me to understand the underlying mumbo jumbo of CQ. The following example is a basic module derived out of the readily available tagging interface, which creates a custom bundle involving the 3 basic steps of development that every developer knows.

Step One: Find — Look before you ask, you may already have it!

My experience working with CQ has taught me that almost all the widgets created for authoring pages exist within the CMS, although many are hidden in one form or another. All that is required is for us to find out where exactly each module is. In the example below, my aim is to create a node in the AEM repository by grouping a number of fields. After some investigation, I found that my requirement matched that of the AEM tagging interface as shown below. The left side of this screen grab shows my custom module built on top of the tagging dialog shown on the right.
There you go, I have found what I need. Now on to the next step.

Step Two: Copy — The only way you can get good, unless you’re a genius, is to copy!

Now all we do is pick up the files from AEM tagging and copy into our local folder. This process is called Overlaying.
My Tag module was available at “/libs/cq/tagging/widgets/” and after overlaying, it is now residing in “/apps/prototype/bundles”
I now have a local module that is similar to my tagging interface as shown below. With this done, all I need to do is chop off the unnecessary bit, which brings us to the final step.

Step Three: Cut — I’m all for the scissors. I believe more in the scissors than I do in the pencil!

The copied module gives the following code structure as shown below. Time for the surgeon in me to step in!
The three notable files that must be changed are:

  • TagAdmin.Actions.js
  • TagAdmin.js
  • TagInputField.js

These provide for the majority of the functionality, for developers experienced in scripting or ext-js, going through the files and understanding the features is pretty straightforward. For the rest, we can follow the good old approach of adding an alert (“This is for new item);”. Regardless of the approach, we have found the files that are responsible for the module functionality. Customizing them will result in our desired functionality.
Once this bit is done, the next thing to do is brand the module. Notice the folder named themes. That folder contains all the necessary styling, which can be modified to set our custom branding. The result is a custom module that meets all our needs. The following screen grabs show the new features
As the screen grabs show a slight but significant difference between the custom module on the left and the default module on the right. Though this process seems easy, it requires a keen eye for bugs, as ext-js is not a friendly language to work with. Usage of the developer tools and firebug, available with almost every browser, will help a lot in deciphering the hidden wiring between modules.
Want to read more about configuring Adobe Experience Manager upgrades? Check out our best practices for upgrading to AEM 6.1 and whether you should upgrade to AEM 6.4.