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
}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 :)
