Hey guys, I just updated YUI and I lost my YUI "dropdown" menus, I tried with YUI menu 1.1 and 1.2 with same result.

Comments

guydaniels’s picture

Me too... using the richtext editor.

tdebruyn’s picture

For me, reverting to 1.1rc2 got the menu to work again.
When you see the diff between 1.1rc2 and 1.2, it is only extremely minor changes. Practically, just 2 "/" have been added in yui.module. It would have been better reflected with a version like 1.1rc3...

bakyildiz’s picture

I am not sure but may be you have to update also yui menu module. Can some one test this and report the result who is not in production?

bakyildiz’s picture

No need to test. I create new release 1.3 to have a working release in module page. Sorry for that.

jfha73’s picture

I don't know exactly where the problem is but having YUI menu 1.2 with YUI 1.1 doesn't work either, I will test YUI menu 1.2 with YIU 1.3 to see how it works, but I think YIU menu needs update too, I don't know if take care of that module too, but I'm going to post an issue on that one too about this.

jfha73’s picture

I don't know about you guys, but in my case it still doesn't work with YUI menu 1.2, I still don't have dropdown menus.

bakyildiz’s picture

Can you sent me your website url?

jfha73’s picture

I have it running with 1.1 both so they are working, but I'm going to setup one with YUI 1.3 and YUI menu 1.2 so you can see it, I'll let you know when it's up.

jfha73’s picture

By the way,

When I check firebug I noticed that in the one where it works it has an iframe from yui with id=_yuiReziseMonitor, but in the one that doesn't work this iframe doesn't exist.

trentl’s picture

Any update on a fix or suggestions to get it working again? After update my site menus failed. I reverted to yui-6.x-1.1-rc2 in conjunction with yuimenu-6.x-1.2 Cannot get it working again. any ideas? My site is currently offline, as I rely heavily on sub menus for navigation.

I have not installed any other modules, other than updates. If lists of my installed modules are required, please let me know and I will post.

thanks

trentl’s picture

I updated to 1.1-1 on both and its now working again. I will hold on upgrades until new releases are complete that fix the issues.

Mornington’s picture

Same here. Dropdowns are absent...

Aximage’s picture

Same here. Dropdowns are absent...

jeremyluby’s picture

I downgraded to 1.1 on both and still have the issue! HELP!!

Alkis’s picture

Assigned: Unassigned » Alkis

the calls to the yui_add_js() from the yuimenu.module won't work as expected if the yui_source is not a remote http source, because if it is not, the scripts will be added long after the: YAHOO.util.Event.onContentReady... which is added to the top of the tag, resulting in the YAHOO not defined errors. If the yui_source is remote, then will be added before the above YAHOO initialization, resulting to no errors.

in a case of a yui_source which is not remote (no http://), inside the yui_add_js, the drupal_add_js will be called, and the specific js code will be added to the scripts area of the template, that is, after the YAHOO.util..... So ERROR.

But if an http url passed, inside the yui_add_js, the drupal_set_html_head will be called instead of drupal_add_js, and the script will be placed before that yahoo initialization code.

In the case of yui menu all those init scripts must be put BEFORE the YAHOO.util... statements. So maybe some new function must be plase inside of yuimenu to do that in order not to break the yui compatibility, or a new function to the yui. There must be a function to explicitly put scripts before any others, and NOT just a regex to check whether or not is a remote url, to put it on top.

rajmataj’s picture

This is also talked about in this post: YUI Menu » Issues » Dropdown dissapeared after update to new version.

My working solution, without downgrading or moving the <?php print $head ?> statement as suggested, was to use an absolute path to the YUI script directory, such as: http://dev.mysite.com/sites/all/themes/[your-theme] but the obvious problem here is that I'll have to adjust this path on the live site to be 'www' and not 'dev' as the former is on my local machine. But, at least it works now and I can move on to other things until this is properly resolved by the developers of the modules.