AEM 6.5: Removing ClientLibs from Experience Fragments exported to Target
Intended Audience
Product and Business Owners, Target Practitioners, AEM Developers, Architects and Consultants.
Overview
NOTE: If you are just looking for the overlays, skip down to Overlays section below.
Personalization with Adobe Experience Manager [AEM] and Adobe Target [Target] was reimagined with AEM version 6.4 (current version as of this writing is 6.5.6.0). Experiences, created within AEM, can now be delivered directly to Target as HTML Offers. This enables the best of both worlds between AEM and Target. Experiences in AEM can be easily created, put through a workflow (approval/governance of content), and then published and exported to Target. Target Practitioners can then, easily, use these offers to seamlessly test and personalize content across multiple channels.
Experience Fragments [XFs] contain full html tags and all of the necessary Client Libraries (CSS/JS) to render the XF exactly as it was created by the XF Content Author. This is by-design. XFs, themselves, can be used in many different scenarios:
- Within AEM Sites
- Via 3rd-Party Consumption: Applications (SPAs), Mobile Apps, etc.
- In Target as an XF Offer
Problem Statement
When using an XF Offer with Target on a page that is being delivered by AEM, the Targeted page already contains all of the necessary Client Libraries. In addition, the extraneous html in the XF Offer is also not needed (see caveat section). Here is an psuedo-example of the html in an XF Offer:
<!DOCTYPE>
<html>
<head>
<title>…</title>
??????<!-- all of the client libraries (css/js) -->
??????…
</head>
<body>
<!--/* Actual XF Offer content would appear here... */-->
</body>
</html>
How to Resolve
At a high-level, when AEM exports an XF to Target, it does so using a couple of additional Sling Selectors. For example, the URL for the exported XF might look like this (notice the bolded items):
- https://www.your-aem-instance.com/content/experience-fragments/my-offers/my-xf-offer.nocloudconfigs.atoffer.html
The nocloudonfigs selector is defined through the use of HTL and can be overlayed by copying it from:
- /libs/cq/experience-fragments/components/xfpage/nocloudconfigs.html
The atoffer selector is, actually, applied post-processing using Sling Rewriter. Either can be used to remove the Client Libraries. However, for the sake of this post, I'm going to reference how to do this via nocloudconfigs. Note, if you are new to Editable Templates, please have a look at Adobe's docs on the matter. Also, there are several good LinkedIn articles written on the topic.
Overlays
In this particular example, the overlays being included will remove the Client Libraries AND the extraneous html. It is assumes that you have already created the XF Template Type. The necessary files that will need to be copied from /libs/cq/experience-fragments/components/xfpage/ include:
- nocloudconfigs.html
- head.nocloudconfigs.html
- body.nocloudconfigs.html
领英推è
Template-Type Overlays
The content of these files includes:
body.nocloudconfigs.html:
6.5.6.0:
6.5.12.0:
head.nocloudconfigs.html:
6.5.6.0 - 6.5.12.0:
nocloudconfigs.html:
6.5.6.0 - 6.5.12.0:
NOTE: I ended up adding nocloudconfigs.html so that I could use 'data-sly-unwrap' to remove the body tag.
Caveats & Considerations
If you need to support both AEM sites and non-AEM sites, using XF Offers in Target, you will want to create 2 XFs (two different template types):
- One with the overlay to remove clientlibs/extra html
- One that doesn't have the overlay and, thus, includes the needed clientlibs
Lastly...
If you find any issues/error with this article, please let me know so that I can update it!
Personalization & Optimization Sr. Mgr at Credit One Bank
1 个月Hi Luis, Did you ever find a working resolution for your issue?
Principal Software Engineer at Microsoft
2 å¹´This worked like a charm. Thanks Todd J. Haser Interestingly, I don't see nocloudconfig being called in the browser developer tools when I export XF from AEM, so not sure where the XF is invoked with nocloudconfigs selector. One nitpick on your blog is that we actually don't need to overlay head.nocloudconfigs.html since the overlay on nocloudconfigs.html is not referencing it anymore.
Full Stack AEM Developer/Architect and CEO at Muchau Software LLC
2 å¹´Good article. I am using this approach, but I have a problem now that the component needs the javascript to execute and it does not work because we do not have the JS in the XF. Looks like I am having a race condition with my clientlibs and target, because the JS that the component needs it is already available in the site global clientlibs but does not fire when Target injects it. Do you know what I am missing?
Adobe Solutions Architect. Senior Technical Product Manager of Digital Personalization at Cloudflare
3 å¹´Thanks for sharing this. I've been digging for a solution like this for a while and the documentation was a rabbit hole.