Jump to content


gsap jQuery plugin conflicts with another jQuery plugin (wowslider)

Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hi. We have a digital signage content editor with many widgets, and 2 of the widgets use gsap with jquery plugin, and we added another jquery plugin for a new widget (http://wowslider.com/), and a few of the features in that library didn't work, I was debugging for a long time when I found that it conflicts with the gsap jQuery plugin, more precisely the easings defined on the jQuery object, for example jQuery.easing.easeInOutExpo, because the easings share the same name in both libraries, but they work differently, the variable has different function references in the two libraries. Currently the gsap definition is in place, which causes some wowslider features to not work.


I tested removing gsap, and then those features worked. I already contacted their support, but they couldn't give a solution, and I want to avoid modifying the code of these libraries.


All I would like to ask for is some tips to avoid this issue. Is there a no-conflict option in gsap plugin? Can I separate two jQuery instances for the two libraries?


Thanks in advance!

Link to comment
Share on other sites

Thanks for the quick reply @Jonathan 


I don't think this would work in my case because the parts referring to the easing is inside those libraries, and not in my own code, so if I would put one of the definitions under a different property name, I would also need to modify one of the libraries to refer by the new property name, which I want to avoid because it would be complicated, and imo a bad practice, I worry it could cause other bugs.


If you suggest this is still the way to go please give some insight. So far I'm thinking about just creating a second instance of jQuery with the noConflict function and give the reference of that instance to one of the libraries, but that also requires modifying one of them.




Link to comment
Share on other sites

Hi again @srmark,


If you look at that stackoverflow article ..

  1. They first include the 1st jQuery plugin...
  2. then they are caching the original function name inside a new variable and then deleting the original function.
  3. Then including the 2nd jQuery plugin script after that new variable and delete.

So order matters in this technique. Their not having to go and modify what is inside the jQuery plugin.




This other stackoverflow link goes over the same situation with conflicting function names of two separate jquery plugin function names. But in this case it is bootstrap jQuery plugin and the jQuery Ui plugin with the same function name inside of them. They do the same thing as above with no delete, and with no need to edit inside both of the jQuery plugins:




Also you could use a closure wrapped around your calling of one of the jQuery plugin so there is no conflict.


  // use j as alias of the factory symbol $, which is an alias for jQuery



Or you can check out this JQuery learning page on what they recommend for conflicts like this, they go over the closure and no conflict:




And this link .. Use An Immediately function expression:







  • Like 3
Link to comment
Share on other sites

Hi @Jonathan


Thanks for the help, I well understand the solutions you linked, but there is a difference in my case.

One widget is initialised something like this: 


The other is initialised something like this:


And the options object does not contain any direct reference to or mention the easing used for the animations in these widgets, the pieces library (which is using gsap), and the wowSlider library both select easing used on their own, based on properties inside the options provided, such as a name for the animation.

My issues comes from the behaviour of these specific libraries. It is the gsap jQuery plugin's feature that it overrides/adds the properties on the global jQuery object used by the animate function ("under the hood"), so old jQuery codes automatically run that. The other library, the wowslider does this very similarly, I don't know for what reason (under the same hood), and the properties that conflict (that I found so far) are in the jQuery.easing object, for example jQuery.easing.easeInOutExpo, which are selected and used inside both of those libraries, that's why I mentioned modifications on the libraries, because if I were to create the two definitions named easeInOutExpo and let's say easeInOutExpo_wowslider by the techniques you linked, I would also need to refer to that new name inside the wowslider library, which I want to avoid.


Both libraries are already written inside an anonym function closure as you suggested, but they are both given the same jQuery object reference as the one paramter at the start, which they modify by reference, so what I was starting to think as a solution, is to create a second instance of that jQuery object before including those libraries, give that other instance to one of the libraries, so the easing they add are not overriding each other, and when initialising the widgets of the second type, use the second instance reference, something like this:

(function ($){
  /* library1 defines easings on jQuery.easings object */

jQuery2 = jQuery.noConflict();

(function ($){
  /* library2 defines easings on jQuery2.easings object */



But I'm not sure if that wouldn't cause any errors, or if there would be any better alternative, please tell me what do you think of this solution.




Link to comment
Share on other sites

Might sound like an odd question, but do you really need the jquery.gsap plugin at all? Why not just remove it? It was intended as more of a band-aid or bridge for people who had a bunch of animations built in jQuery already and weren't quite ready to rewrite in the GSAP syntax but I'd strongly recommend moving away from depending on that plugin if at all possible. The native GSAP syntax is going to deliver a lot of other benefits (more flexibility, even better speed, improved compatibility, etc.)

  • Like 4
Link to comment
Share on other sites

Yes i was thinking the same thing.. ( but kept my big mouth to myself :huh: ),


Why not just use TweenLite or TweenMax, instead of the jquery.gsap plugin as @GreenSock Jack suggested. It will allow you to have more control and less jquery conflict city :)

  • Like 4
Link to comment
Share on other sites

Hi, thanks for the replies. The greensock-based library is provided as is, I just call the pieces function on an element with some options, and it animates it. I'm not at work until next tuesday, so I can only run it and check if it works without the plugin then. It is in the system for a long time, so I don't remember how exactly it is being included, but it might be necessary.

Link to comment
Share on other sites

  • 2 weeks later...

Hi, the issue was resolved by removing the jquery plugin, thanks again.

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.