ajaxsearch.pro.js collision with inclusion of jquery.ui

[eggmattersParticipant]

I am developing a plugin for the above website. After doing an update, the site author had added this plugin. All of my jquery.dialog frames are now broken. In my plugin, I deregister jquery & jquery-ui as I have more up-to-date versions (I would also like to integrate theme roller in the future.)
At any rate, glancing at your min, I noticed that you’ve basically copied jquery & jquery.ui in your script, thereby causing a namespace collision with plugins that may be reliant on cdn’s or their own sources for jquery-ui.
An ideal fix would be to namespace you’re jquery:

MyJQ = function() {
jquery_definition et. al.
}()

Since this is an ecommerce service and the functionality I’m writing is reliant on secure customer data, I can’t grant full-fleged access to the site. I will be happy to share any code snippets and design patterns though.

• This topic was modified 9 years, 2 months ago by  eggmatters.

[Ernest MarcinkoKeymaster]

Hi!

I just looked at the search main source. Is this happening on the post editor page?
Currently the built in UI is only loaded on the search backend pages and on the post editor.

However I’m not sure why I enabled it on the post editor, it might have been a mistake. If you open the plugins/ajax-search-pro/ajax-search-pro.php and go to line 85 where you should see this:

require_once(ASP_PATH . "/backend/settings/types.inc.php");

then try to comment out that line, because I believe it’s not necessary to include that file there:

//require_once(ASP_PATH . "/backend/settings/types.inc.php");

Try to refresh the page, and the UI and all the other js and stylesheet files should be gone on the editor page afterwards.
Let me know if this was indeed the issue, so I will add it to the bugfix list.

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

[Ernest MarcinkoKeymaster]

Side note:

I got a mail delivery status failure from your profile, so I looked and your mail address looked incorrect, it was **@monsooncommerc.com, I figured it missed an e from the end so I changed it to **@monsooncommerce.com

Hopefully you will get the support ticket notifications now.

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

[eggmattersParticipant]

Thanks for your response and my apologies for the boffed email. I did comment out line 85, and no luck. The behavior I’m describing is a page rendered by my plugin. At it’s core, it is an assembly of shorttags which render formatted html snippets of data made by api calls. Some of these render forms as modal dialogs via qquery-ui. With ajax-search-pro enabled, the dialogs fail to load. Firebug shows the following:

TypeError: $(...).dialog is not a function

I’m seeing the inclusion of jquery-ui in my script loads, but I believe it is a namespace collision with the inclusion of ‘ajax-searchpro.js’.
The page dependent on rendering this data does not include the search bar shortcode, but wp will load the plugin anyway.
My plugin makes several api calls. To ensure that these calls or only made when needed, I wrote a filter will only make api calls etc, if a specific shortcode is included.
I load a local copy of jquery-ui, not the cdn or the built in wp instance. I therefore disable these. I have my own javascript inclusion set to load preferably last:

add_action('wp_enqueue_scripts', array(&$this, 'addScriptTags'), 999);

And then I deregister jquery & jquery-ui and register my own:

function addScriptTags() {
    $today = date('Ymd', time());
    wp_deregister_script( 'jquery' );
    wp_deregister_script('jquery-ui-core' );
    wp_deregister_script('spin');
    //wp_deregister_script('wpdreams-ajaxsearchpro');
    wp_deregister_style('jquery-ui');
    wp_register_script('jquery', plugins_url('views/js/jquery.js', __FILE__), array(), null);
    wp_register_script('jquery-ui-core', plugins_url('views/js/jquery-ui.min.js', __FILE__), array('jquery'), $today, null );

When wp_deregister_script('wpdreams-ajaxsearchpro'); is uncommented, I get the following errors:

Notice: Undefined index: wpdreams-ajaxsearchpro in /var/www/html/wp-includes/class.wp-scripts.php on line 200
Notice: Trying to get property of non-object in /var/www/html/wp-includes/class.wp-scripts.php on line 200

Which is odd because, I specified a pretty higher priority number to my enqueue scripts than you did (me: 999, you: 10). The deregister should definitely be called after your scripts have been registered.

• This reply was modified 9 years, 2 months ago by  eggmatters.
• This reply was modified 9 years, 2 months ago by  eggmatters. Reason: add function name for clarity

[eggmattersParticipant]

Looking at your jquery.ajaxsearchpro.js It looks as if you’ve redefined ‘$’ in context of your plugin. This is also in wpdreams-aspjquery. Disabling these scripts gets jquery-ui to load properly and render my modals but I still get the above ‘not found’ & ‘udefined’ errors.

[eggmattersParticipant]

I was able to successfull de-register the conflicting scripts and dequeue them, causing the errors to go away:

    wp_dequeue_script('wpdreams-aspjquery');
    wp_dequeue_script('wpdreams-ajaxsearchpro');
    wp_deregister_script('wpdreams-aspjquery');
    wp_deregister_script('wpdreams-ajaxsearchpro');
    wp_deregister_script( 'jquery' );
    . . . 

This is not ideal as it introduces a dependency on my plugin to your plugin. I am still curious as to why the scripts aren’t compartmentalized. Looking at the high compatibility, minified code, it looks like it shouldn’t case issues as it is, in fact, namespaced.

[Ernest MarcinkoKeymaster]

Hi!

That’s what I was going to say. There are 4 different sources availabe for the scripts. Two of them is namespaced (scoped). By default this namespaced version is in use.

Before jumping into changing the code, you should try out the non-namespaced versions first. It helped once someone wiht a similar issue, it wasn’t jquery UI but something else. I’m working on these javascript compatibility issues over 2 years now, and I honestly have no idea how a namespaced js can conflict with an entirely different one – it beats me.

Anyways, on the backend, go to the Compatibility Options menu under the ajax search pro menu bar. There should be a dropdown box with the JS source. Try the minified or the non-minified one. I have a feeling it will help.

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

[eggmattersParticipant]

Thanks Ernest. I tried variants of the namespaced & non-namespaced scripts. Sorry I made the wrong assumption there. After looking at your code, I see you are indeed namespacing it correctly. My guess is that jquery (‘$’) is a global variable and in js, when you change something, you change it. What else is wierd is that jquery is just fine. Your code doesn’t appear to have any jquery-ui in it (although I didn’t look too hard) so, it is odd that it breaks. I’ve never seen it before. Thanks for looking into it though.

[Ernest MarcinkoKeymaster]

No problem at all.

I had to include the namespaced script versions as well mostly because of these types of conflicts. You don’t want to know how many times I have seen different jQuery versions manually included in site header AFTER the wp_head() call. The users were wondering why none of their jQuery plugins were working, and of course blamed this ‘stupid’ plugin and left a 1 star rating without asking.
Thank god this fix works more than 99% of the time.

But probably the biggest and almost unfixable issue is the CSS conflicts because of themes. Let me show you a CSS rule from the Avada theme, which is the #1 best seller item on themeforest:

#header-sticky .login-box .forgetmenot input,
#header .login-box .forgetmenot input,
#small-nav .login-box .forgetmenot input,
#side-header .login-box .forgetmenot input {
   margin:0
}

You can check that out here: http://theme-fusion.com/avada/wp-content/plugins/w3-total-cache/pub/minify.php?file=VY7NDoMwDINfiCrjtPPuu-0JQhtQpP6gOjDx9oMyIXGJ7E-O5Z7evEn9RA1SCcamnjxA8cBouHvQa-XAjQ_DXAXoevIlG3tzY6nJPUmzj0sQtBRsi3KEqqxnCVW4OS6T5jMgZponXN3t43Lj3o12-SsoSZp2f3MbxFnTvrpk3HCSoHwjOnP4AQ.css

It looks harmless, but it’s this causes extremely huge issues. I’m not sure how familiar are you with CSS precedences, but an element targeted with an #id selector can’t be overridden by class selectors. So if the user puts the search shortcode within those elemenents, and in the search code I want to change the input margin I can’t do this:

.ajaxsearchpro input.proinput {
   margin: 10px;
}

Because the theme rule will override this. The only possible solution if I use an #id for the ajax search pro. BUT, the plugin shortcode is re-usable, thus multiple instances MUST have different #ids, so how can I target those with a single CSS selector? I tell you how – impossible.

I’m not saying that theme is not good or anything, but WHY on earth does he use freakin IDs?? There is no reason to do that at all.

I had to work straight 2 days on a solution to introduce a new option for the upcoming search version: Adjustable CSS compatibility levels
It’s an extremely nasty dynamically-generated solution – basically it let’s the user to choose higher compatibilty level if something is not right on the frontend. The highest level generates lots of unneccessary CSS just to bypass the #id issue. It’s insane.

I wish themeforest had higher standards at reviewing items, or provided some kind of guide to prevent these issues. It’s always the plugin developer to blame, never the theme developer.

I’m sorry for the long writeup, I hope it wasn’t too boring 😀

Anyways, if you need any more help or assistance, let me know!

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

[Author]

Posts