A Bug with Targeting in AEM 5.6 and a Workaround

While working on upgrading a site from Adobe CQ 5.5 to Adobe Experience Manager (AEM) 5.6, we found a new button (Target) that when clicked, seemed to break every component we had. AEM 5.6 introduced the target button to the toolbar of every component. This button is designed to target the content in order to give a user-specific experience that can be tied into Adobe Test&Target. You can then manage your experiences through the Marketing Campaign Manager (MCM) to make your content adaptable and dynamic.

After much investigation, we determined that the bug is encountered when a component is directly included on a page and the target button is clicked. We will go through the problem, cause, and a couple of solutions in the following post.

This is what the target button looks like:

component-bar

Below is the node structure and properties for bannercarousel (sling:resourceType = brianfanclub/components/bannercarousel.) The component is on our homepage and contains three bannerimages.

Initial-Structure

bannercarousel-CRXDE-properties

In the makeup of the homepage, promos.jsp pulls in the bannercarousel with cq:include.

promos-jsp

Initially, the bannercarousel is configured to have three bannerimages through a pretty simple dialog. Each bannerimage has its own dialogue that controls the image and associated options.

carousel-component-1

carousel-component-properties

If we hit the target button, the page refreshes and it gives us a blank component with a blank dialogue.

blank-slide-component

empty-carousel-component-properties

In the node structure, there is a new node called “default” that inserts itself between the bannercarousel and the bannerimages. The bannercarousel node is now sling:resourceType = cq/personalization/components/target.

node-with-target

banner-properties-after-target

This is the default node’s properties. It has the content we expect to be in bannercarousel. Let’s hit the target button again to make sure:

Default-node-properties1

We get another default node nested below bannercarousel.

default-node-nesting

The problem comes from cq:include:

path=”bannercarousel” no longer has its resourceType=”brianfanclub/components/bannercarousel”—it has become cq/personalization/components/target. Pressing target wraps the component in an mbox that has its own properties but takes the name of the contained component. It renames the targeted component as “default” inside of the mbox. cq:include cannot find a bannercarousel, so it gives you a blank component, as if you meant to add the component to your page but have yet to set it up.

We got around this mix-up by creating a custom tag library with an “axis:include” tag. Check out this link for guidance to create your own tag library: http://docs.oracle.com/cd/E11035_01/wls100/taglib/quickstart.html.

This is our custom include tag code:

Our tag handles three cases:

  1. If there is no path or type given, we call the normal cq:include. This will put a blank, fresh component on the page.
  2. Next, we check the page’s nodes for our component based on path. If we do not find the component by path on the page, we call cq:include, which will give a blank, fresh component.
  3. If we do find our node based on the path, we set the sling:resourceType to whatever we find that the node has and then pass it to cq:include.

When bannercarousel has a type “target,” the axis include changes the sought after component to have type target. cq:include is able to recognize type target as a targeted component.
Using our tag, target behaves as it should:

targeted-bannercarousel

targeted-nodes

targeted-node-property

The node structure is the same, but axis:include handles the case when bannercarousel is type target. Hitting the Disable Targeting button will revert the mbox and the component go back to normal.

To manually recover a node buried by mboxes, just go down the node structure until you find the default node with the properties that your component expects. Drag the default node out to where the component should be. Delete the old node with your component’s name; it is just a bunch of nested mboxes now. Rename “default” with the correct component name since it now contain the data that was lost.

fix-nodes

Another, quicker fix is to disable the target button on a component. Add a cq:editConfig node to your component if it does not have one already, then add the property cq:disableTargeting=”{Boolean}true”. You would have to go into every component (whether it is custom or from the foundation) to truly disable targeting throughout your site. Changes in libs can be in danger because your modifications will be overwritten with each AEM update. Creating a new tag is a better option.

edit-config-node

edit-config-properties

Keep in mind that this issue is only encountered when the component is included directly on the page. If it is included through a parsys, you get the correct targeting behavior without any modification. This workaround helps you use AEM’s targeting feature as it was intended, providing custom content for your users. Stay informed on AEM workarounds, subscribe to the Adobe Experience Manager Podcast today.