Jquery conflict

This topic contains 11 replies, has 2 voices, and was last updated by

5 years, 5 months ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
  • #9716


    Hi there.
    We just purchased the plugin and want to use it as a replacement of our regular wp_search function.
    Problem is : once activated, we have a JQMIGRATE nitification in console, and an error with our previously working scripts.
    My guess is that your plugin is relying on old jquery version, and uses the wordpress jqmigrate to “work”. Problem is that is introduces an issue somewhere leading to a changed order of loading of the scripts, killing what was working (here in this case, i’m using velocity.js and the error i have is velocity is not a function. So, velocity not loaded at the right time, and creating an error when reading my other scripts code)
    Are you integrating a jquery version inside your plugin ? Is there a way to bypass that so only one version of jquery is loaded (and the console wont tell us about jqmigrate anymore) ? Is there any other solution ?

    Thanks in advance.

    You must be logged in to view attached files.


    Another view of where the bug happens with my scripts.

    You must be logged in to view attached files.

    Hi Mat,

    The plugin does not use the jqmigrate plugin, it works with the latest built-in wordpress jquery version.
    The jqmigrate message is default in the latest wordpress core, it’s displayed on a fresh wordpress installation as well, with no plugins enabled. (at least for me it does)

    Does the velocity error disappear when the plugin is disabled?
    Can you please update your ticket with temporary FTP and log-in details? I have no idea how the plugin would affect the loading order of the velocity script, but I gladly debug through the plugin code to find the issue.

    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)



    Hi and thanks for your fast answer Ernest.

    The velocity error disappears when the plugin is disabled. Everything is working fine without the plugin. The plugin introduces something in the loading of the different javascript scripts.
    Velocity is a great library for animating : it’s way faster than jquery. And in this case, i am using it to animate big chunks of the site.

    I have not loaded the scripts inside wordpress with a clean declaration (i beleive i should enqueue them somewhere ?) and am writing them directly in the header with a file_get_content (this, to be sure scripts are loaded in a particular order). I don’t have a big experience with plugins creation and wanted to stay ‘independant’ from wordpress by doing so. Maybe it’s the reason i have this issue now ?

    I cannot give you FTP access sadly, but if we have no choice i will try to create a limited FTP access later. It’s just time consuming with our process.

    Here is the site we are working on : http://anewmars.com/00_dev/ellipse-avocats.com/
    I left the plugin activated, so you can see the error popping.

    Is there anything i can do to try to debug this ?




    Well, I don’t know it it’s related, but I see 2 instances of jQuery loaded within the same scope. One is after this line in the header:

    <!-- Some inline Javascript for fast loadings -->

    The other is the built-in jQuery. I believe the first one should not be there at all.
    Then if I try to access:


    in the console, it returns undefined – which suggests that the script is not loaded, but


    returns a function. Meaning that the $ scope is a different jQuery or the velocity script is not loaded there.


    1. I would recommend removing the first instance of the jQuery, it’s unneccessary, and it’s overwritten by the built-in jquery anyways.
    2. Try changing the ready statement you use in the header from:




    It’s much better, as it will always use the original jQuery, and pass it on as the $ into the function, so you can still use it in your code.

    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)


    Also, you should consider moving the header inline scripts to the footer since it’s only executed on the window.ready event, so it makes no difference at all. Or at lease move it below the wp_head() call within the header.php file, to make sure that the built in jQuery is loaded by then.

    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)



    Hi Ernest.

    I had to dig up and force myself to use the enqueue script stuff in the wordpress functions.
    I didnt want to in the first place, because ‘photon’ had to be loaded before the document completion in some cases. Nevermind.

    FYI i enqued everything, have the JQMIGRATE text showing in console, and cannot override wordpress basic jquery with a more recent one. I wanted to integrate jquery v3+, but your plugin isn’t compatible (some ‘on’ and ‘load’ are no more written the same way. No big deal, but you should consider looking into that 🙂 ). So yeah, i had to use the native jquery, and downgrade some stuff in my scripts to get everything working as expected or almost as expected.

    Good news is… i am fully operational again, the previous scripts are almost 100% functional, and the search is fully working.
    Now to stylize it !

    quick notes :
    – the scrolling behaviour in the dynamic search is buggy under OSX
    – i have not found yet a way to stylize the scrollbar. Still looking. If it’s not available, make it so please ! 😀
    – I will also add some CSS styling to this. Not sure yet where to put that, will look into it soon too.

    Thanks for your time, very appreciated !

    Best regards,



    Okay, still got some conflicts here.

    I know it’s a bit out of the scope of your plugin, but since it’s induced by it…

    Try on the right hand sign to use the contact button : the overlay shows up, but the modal comes way after.
    I suspect the Jquery version, since it was working flawlessly just before.
    When enqueing the script, maybe i have to change the dependencies, or i don’t know, use a more recent version of jquery, still compatible with your plugin ?

    Using this atm :

    wp_register_script('iziModal', get_template_directory_uri().'/js/iziModal.min.js', array('jquery'),'', false);

    Got any idea ?



    Hm, i tried to put the latest Jquery and it didnt fix the izimodal behavior. I guess it’s more an issue of the modals themselves, with the enqueues.



    In addition to my previous answers, I have forgot to mention that it is possible to change the script scope on the Compatibility Settings submenu: https://i.imgur.com/YiL7azr.png
    I suggest using the “minified scoped” option if you are planning to experiment with different jQuery versions. In this case the plugin loads a bit of extra code, and mimics an own jQuery scope separated from the one loaded by wordpress – thus it gets completely separated from dependencies.

    However changing the jQuery versions is not the best idea, as every plugin developer makes their plugins to be compatible with scripts used by the wordpress core. In your case the problem was caused by this scenario:

    – On the top of the page there was a manual jQuery loading separate from the core
    – Then your scripts followed, which were executed right after the custom jQuery load
    – Then the wordpress core jQuery was loaded, because ajax search pro was activated. It was not the plugins fault, any other plugin requesting jQuery would triggered the same behavior. And most plugins do use jQuery.

    The problem here is that the first jQuery loaded up to variable scopes “$” and “jQuery”. Then the second, core load overwrites that, but for some reason only the “$” variable scope. Now the first jQuery is within the “jQuery” scope, the second in “$”. However plugins tend to use the “jQuery” scope and the “$” as an alias to that same scope. So using the “$” variable in your scripts however was not an alias to the original scope, but a different object.

    This is one of the main reasons not to do that, unless you have a very good understanding of variable scopes and jQuery itself. Another reason is compatibility. New plugin versions will come out one after another and all of them is created to the jQuery within the wordpress core. Therefore there is a very high chance of plugin updates breaking everything.

    I hope you don’t mind I share this information with you. I’ve done a good amount of experimenting with these, and I also did replace core jQuery and done similar stuff, but it all lead to more and more issues. I did use the velocity script as well, but eventually dropped it, as it was unnecessary once I understood how to use pure CSS3 animations instead. Still a solid choice if you use lots of separate animations at once.

    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)



    Hi Ernest, and thanks for your insights !

    Yeah, i kinda figured out when debugging the issue, that wordpress loads his own Jquery (except in child themes, where you have to add some code apparently), and reading here and there that you should use this version when developping plugins for wordpress. For simplicity, scope issues, loading times, … and mostly because it’s already bundled in WordPress. And modifying wordpress when using one plugin is not something you can tell your clients.
    So yeah, i did change a lot of things, including moving the calls in the functions.php (enqueuing), uing jQuery(something) instead of $(something) etc etc.
    I dont see any performance change, but the problems have disappeared. And… i even fixed an issue with a call i made in photon where i was trying to reset the facebook call for sharing an article, and got errors in the console even if the share worked fine. So i guess i even fixed that too.
    I had issues with linkedin, though, and had to replace the share button. But meh, i’m fine with it.

    I only have ONE issue now, which is not causing me any trouble i guess, but prints an error in the console. After a couple clics i got this ‘KeyboardEvent.keyIdentifier’ is deprecated and will be removed in M53…
    but i THINK it’s because i use Vivaldi and got an update yesterday. Just wanted to let you know, cause maybe some calls to your functions use this, and might get obsolete with the next chrome version (vivaldi uses chromium).

    Thanks again for the long answer and your enlightments, they really helped !

    Best regards,

    You cannot access this content. Best,
    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.