Expand my Community achievements bar.

Applications for the 2024-2025 Adobe Experience Manager Champion Program are open!
SOLVED

Overriding version of jQuery when using Target

Avatar

Level 1

Hi

It's been nearly 5 years since this question : https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/jquery-conflict-in-aem-6-4...

We still have the same problem - AEM insists on loading the 'jquery' clientlib when you add things like Target integration to your pages.  This results in jQuery v1.12.4-aem being loaded, which is really rather old.

The workaround, as described in the answer to the earlier question is to create your own clientlib which loads a newer version of jQuery, and to make your clientlib depend on the AEM jquery clientlib (so the AEM version loads before yours), and to make sure you load that before anything that requires jQuery.  The end result is then that the version of jQuery you want to use is loaded, and because of the way clientlibs work, there's no further attempt to load v1.12.4-aem.

However, the downside of this is that the browser requests, downloads, and parses a version of jQuery that is never used.

Does anyone have a better, more performant approach to this issue?  

As an example, this is what happens if you add Target via Cloud Services if you don't somehow trick AEM by loading the OOTB 'jquery' clientlib earlier in the page.

simonc39079524_0-1701172311564.png

 

1 Accepted Solution

Avatar

Correct answer by
Level 1

I found the solution.  Hopefully others will benefit from this, as most other posts I've seen on the subject result in double loading of jQuery and the need to carefully manage how and when you load the clientlib which contains the version of jQuery you want.

First though, the OOTB version of jQuery is an updated version of v1.12.4 it already contains fixes for the known vulnerabilities.  So if you are looking to update jQuery simply to pass a security scan, then you should read this:

https://docs.mktossl.com/docs/experience-cloud-kcs/kbarticles/KA-21173.html

If you still want to use a newer version of jQuery, then the solutions is really simple.

Create your own clientlib that contains the version of jQuery that you want.
Set the categories property of your clientlib to be "jquery".
Set the replaces property of your clientlib to be "/libs/clientlibs/granite/jquery".

simonc39079524_0-1702641371537.png

Then add your clientlib to the page as required

 

<sly data-sly-call="${clientLib.js @ categories='jquery'}"/>


The key point is to set the 'replaces' property, otherwise you'll end up loading both the OOTB code and your own version.

View solution in original post

1 Reply

Avatar

Correct answer by
Level 1

I found the solution.  Hopefully others will benefit from this, as most other posts I've seen on the subject result in double loading of jQuery and the need to carefully manage how and when you load the clientlib which contains the version of jQuery you want.

First though, the OOTB version of jQuery is an updated version of v1.12.4 it already contains fixes for the known vulnerabilities.  So if you are looking to update jQuery simply to pass a security scan, then you should read this:

https://docs.mktossl.com/docs/experience-cloud-kcs/kbarticles/KA-21173.html

If you still want to use a newer version of jQuery, then the solutions is really simple.

Create your own clientlib that contains the version of jQuery that you want.
Set the categories property of your clientlib to be "jquery".
Set the replaces property of your clientlib to be "/libs/clientlibs/granite/jquery".

simonc39079524_0-1702641371537.png

Then add your clientlib to the page as required

 

<sly data-sly-call="${clientLib.js @ categories='jquery'}"/>


The key point is to set the 'replaces' property, otherwise you'll end up loading both the OOTB code and your own version.