Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Conflict with WP admin bar #14
Great to hear from a die-hard Superfish fan :)
I've tried to reproduce this issue but it works fine for me. I use WordPress daily and haven't seen the issue. I wonder if it still happens for you if you change the theme? Can you try that please? It would be good to figure out what is causing the issue and fix it if it does turn out to be an issue with Superfish.
Amazing work. Your screencast really removed any question of there being a problem, I really appreciate the effort!
This explains why only the hover events are affected and not the
wp_deregister_script('hoverIntent'); wp_register_script('hoverIntent', ( '/path/to/hoverIntent.js'), array('jquery'), 'r6.1');
More thorough solutions:
Thanks so much for bringing this to my attention. Please let me know if this fixes the issue for you.
referenced this issue
Mar 7, 2013
All right, it works! You rock, thank you very much. About possible solutions. I'm for disableHI to true for the next release (temporarily?), this could save a lot of headache for someone. The ideal solution involves a lot of variables, so yes I guess it's far from an instant :)
Got a curly one for you, as I've found this behaviour is still happening in our WP site. When disableHI is set to "true", the hoverClass correctly appends to the LI elements with child menu elements. However, when disableHI is set to "false", the hoverClass is instead appending to the top level UL. Menus expand on right-click but not on hover as a result of the hoverClass appending incorrectly.
Now I have been able to patch in a temp work around. I changed line 60 from
$menu.hoverIntent(over, out, targets);
$('li:has(ul)').hoverIntent(over, out, target);
which seems to work for now but, but not being the most adept at JS am not sure whether it the best option. Could the hoverIntent events be bound using
.onas the variables in the next section
$menu.on('mouseenter.superfish', targets, over).on('mouseleave.superfish', targets, out);
works without a hitch.
To be quite frank this has had me stumped for days
Also note that although I'm running latest releases of jquery & jquery ui, temporarily reverting back to the original WP releases made no difference either.
Thanks again - E
I created my own set of files from that test page and set about deleting everything not related to Superfish. It turns out that the file named "jquery.slick.contact.1.3.2.js" includes its own (old) version of hoverIntent. Deleting that fixes the issue.
Hope this helps.
Wow, nice pick... thankyou so much for that. I'll advise the developer of the plug-in, as bundling hoverIntent into the source code when WP already includes a more recent version is a no-go.
BTW... one other difficult I'm having. In the older builds the submenu indicators were in a separate span making hiding the top-level quite easy. These new csArrows seem to make use of Toggle(show/hide) function in jQuery itself and thus Superfish doesn't seem to generate the rules of application.
Is there any means beyond css of removing arrows from top menu level only and retaining for deeper nesting?