3rd-party module AJAX not working within a Menu Minipanel

Yes. I am having the same problem with a Views Slideshow (that is inside the Menu Minipanel).

Any work arounds?

Updating to latest DEV version resolved the issue for me.

Having this problem as well. I have a view block with Views Slideshow in a Menu Mini Panel, and the slide is not advancing. Funny thing is, the pager is advancing, just not the views row. Did test in a non-menu panel, everything is fine.

I did upgrade to 7.x1.x-dev (2011-Jan-11), did not resolve the problem.

When I get a moment (HA), I am going to see if I can force it at the theme level, just using the output of the QTip. I am wondering if the way the QTip loads, it may be breaking the selector the cycle plugin is trying to use, but then, it is still cycling the pager.

If anyone has thoughts on this one, please post back.

After inspecting the dom, what appears to be happening is, when QTip loads, it essentially duplicates the content in the panel, including the IDs and Classes. It seems that the slideshow plugin attempts to select the ID of the slide, it sees only the first one that appears in the DOM. Inspecting the dom reveals that cycle is, in fact, working on the first instance of the view in the mini panel that is not in the QTip. (You can see the inline styles changing with the cycle as expected).

So, where does this leave this issue? I am not too sure, but the problem appears to be two fold. First, Menu Mini Panels should probably not duplicate item IDs without first removing the originals from the DOM. Second, Views Slideshow maybe should not rely on IDs for it's element selector. Using the class would probably eliminate this problem.

At this point, I am going to hit up the Views Slideshow crew and see if there is a possible patch or work around for this issue. It would be totally awesome for me to be able to have slideshow in my Menu Mini Panel, don't you think?

I am not running slideshow I am simply using Menu Mini Pannels with Quick Tabs and I am seeing the same issue, I create a mini panel I load a quicktabs block into it and then assign a menu item as a menu mini panel. When I then load the quick tabs in the menu mini panel the block loads and when you click on a tab link it does as was explained in 1, it reloads the whole page. I have tried to tell ajax to load all tabs at once and no change, I have also told ajax to load only one tab at a time and no change.

Is this being looked into? There are no errors being reproduced on the drupal end and no errors within PHP it looks to be an AJAX, Javascript issue (not my area of expertise if I do say so) I was wondering what was going on as currently I do not think that menu mini panels supports quick tabs until we can get this problem sorted out?

Are there many other people using it? Maybe it could be a module clash or something? If I can provide further information let me know as I would like to see this problem sorted and how no problem lending a hand??

erok415 , Yes I am expereiencing that problem as well re loose of connection to the JS function and Quicktabs acting like it can not see the JS turned on and degrades?? Should this be listed as Menu Mini Panels or with QuickTabs?

Please update to the latest codebase (currently in git, will have a new release soon) and let me know if the problem persists. Thanks :)

I should also say that I've a suspicion this may not be fixable until changing from qTip v1 to something else, e.g. qTip v2. Please keep an eye on #1253432: Upgrade to qTip v2 and #1380058: Refactor module to allow for pluggable libraries.

I'm having a similar issue with a custom JS widget being called into my menu_minipanel. It seems to be doing the "degrades gracefully" thing. The widget will work in any other region on the page just not in the menu - it acts like JS isn't enabled. I also tried updating to the latest codebase with no results.

Scenario A may work now, with the code I've just committed to the -dev version. Scenario B, i.e. all of the JS-driven interactivity, will take further effort to debug.

Patch attached. As scottsawyer correctly surmised, the problem comes from cloning the content, resulting in duplicate CSS ids. This patch allows views AJAX to function correctly in a menu minipanel for me, and I suspect it would fix the quicktabs issues as well. This patch depends on the patch in #1253432: Upgrade to qTip v2 to allow the use of qTip v2, I haven't tested it against qTip v1. I don't know what the original motivation for using clone() was, so I don't know what the possible drawbacks to this patch are. However, I'm not seeing any problems in my testing so far.

I've hit this too now.
Loading an AJAX-powered view (a views glossary) into a mini panel was failing.

Eventually traced it to the same point. Due to the use of clone() the attached behaviors that views had added were being lost.
I found that changing jquery clone() with clone(true) [withDataAndEvents] solved my issue. But still would potentially leave the duplicate ID problem discussed above open.

However, Testing without clone() at all as patch #14 seems to work fine now also.

Re-roll of #14.

As @acrollet mentioned, I'm not sure the original motivation for cloning the content to begin with, but I can confirm that #16 fixed my broken panel tabs.

#16 fixed issues with ajax based views as well. Though I had to manually apply the patch.

#16: menu_minipanels-3rd_party_AJAX_not_working-1281862-16.patch queued for re-testing.

On #16: Removing .clone() indeed solves the issue but causes content appearing in minipanels to appear bottom of the page in addition causing duplicate content there. Rubberbanding it via display:none; works but is flakey solution at the best.

Details:
Custom Zen-based theme with region .region-page-bottom
Minipanels attached to menu items are view blocks and are duplicated to the region mentioned if .clone() is disabled.

Yes.
On testing (after I rolled #16) I also found the panels becoming visible at the bottom.

* I found that changing jquery clone() with clone(true) [withDataAndEvents] solved my issue.

And I've been using that method instead since then.
I was surprised that #17 and #18 reported no problems, so I guessed it was something to do with my theme (Omega-based).

Can you provide a patch? Or paste the complete line from menu_minipanels.js (I'm assuming all the changes reside only on the specific line).

Doing it by hand --- it would be

diff --git a/js/menu_minipanels.js b/js/menu_minipanels.js
index 6c783e3..e1ced30 100755
--- a/js/menu_minipanels.js
+++ b/js/menu_minipanels.js
@@ -20,7 +20,7 @@
           })
           .each(function () {
             $(this).addClass('minipanel-processed');
-            setting.content = $('div.menu-minipanel-' + setting.mlid).clone().show();
+            setting.content = $('div.menu-minipanel-' + setting.mlid).clone(true).show();
             setting.hide.fixed = true;
 
             // Specify a custom target.

I'm trying to get into using git format-patch, see if this works

Yeah, so I should use --relative there..

Actually I was unable to apply #16 so ended up doing it by hand. No idea though what causes that (Probably causes the simple tests to fail)

Actually I was unable to apply #16 so ended up doing it by hand. No idea though what causes that (Probably causes the simple tests to fail).

Applied #23 manually but the duplicate content appears in footer.

#23 worked for some time but now it seems to require inputting twice. Aka if you want to search using input field you get following behaviour: You write text and press submit (ajax), text disappears, ajax doesn't trigger. Repeat and ajax does trigger.

This is nerve wrecking. I have been banging my head against the wall trying to figure out solution for this for 8 hrs today as this is critical for our project.

@Demoshane it sounds like you are talking about the AJAX of the other feature now. And that's all about the secondary code. It will depend on how you are applying that behavior.
To be Drupal-compatible, and work on pages or parts of pages that may be hidden at load-time, your code must be using Drupal.behaviours and wrap its initialization routines inside once() or similar.

This ensures that :
* dynamically loaded parts of the page get javascript behaviors added to them correctly as and when they show up. Or changed.
* the events are only triggered once, otherwise you may find yourself acting like a button was clicked 1,2, n times depending on what else has been loading on the page.

* Do NOT USE document.onload, or even the jquery ready() method. You must use the behaviors wrapper.

#31: Actually I was talking about simple view which consist following: Display all content, title field and exposed filter for title. Use AJAX = Yes. No custom code whatsoever, but just a plain basic view. Many other megamenu solutions seem to suffer from the same but after thorough testing om_maximenu seems to have a working AJAX.

I have to dig through the code at some point I manage to arrange time and try to figure out differences.

Purely CSS, script-less solution for Drupal 6 based on this module codebase

I was struggling with allowing arbitrary AJAX-powered content for few days.

On my D6 installation tried updating to qTip2. This requires jQuery 1.7. But neither Drupal core, nor jquery_update.module allows going that far in the future. So i've tried backporting qTip2 using some hackish "polyfills" found all over the internets to make it accept jQuery 1.3 -- failed miserably, because ultimately jQuery added too much on a conceptual level over few versions.

Hack with `.clone(true)` didn't work for views.module: AJAX-enabled pager "spinning" but then nothing happened.

So, at last i decided to rewrite menu_minipanels.module, as noticed some potential to minimise and streamline it's codebase. Namely, some initial observations:

• This module renders panels into footer and then does complicated effort to associate them with menu items. Because generally relation between panel and menu is not 1:1, that infamous .clone() is necessary to inject panel DOM into menu. My thought: why not to inject panel HTML directly into menu markup
• This module uses significant number of settings to control panel rendering: corner rounding, arrow position, and so on. This seems redundant, as panels.module has it's very own extensible styling opportunities.
• Finally, pure CSS might be sufficient to display panels on mouse hover, so dependency on qTip2 becomes redundant.

Please see resulting slimmed-down module attached. Most of the original complexity has now gone: no CSS, no JS, no qTip, no settings form, no drush script, no installation code. What remains is: single drop-down box per menu item to associate it with a panel, and corresponding code to render it into menu.

What's required from a CSS side is few rules like these:

.main-menu li .panel-myLayout {
  position: absolute;
  left: -999cm;
  z-index: 99;
  min-width: 740px;
}

.main-menu li:hover .panel-myLayout {
  left: inherit;
}

What this CSS does is:

• position panel absolutely
• effectively hides it from a viewport by pushing it far to the right (when using 960 GS this will always work)
• put panel into sight on hovering it's common container with menu item

There're some issues still remain, maybe someone could shed a light(?):

1. I don't fully understand all manipulation with Drupal hooks in PHP code of this module. So implementation looks cargo-cultish -- you can easily spot where was the doubt.
2. Although, rendered HTML looks fine, some JS gets in the way and adds some anomalies at least to a first menu item. In my case menu item A-tag was duplicated several times inside panel's nested DIV-tags.

Otherwise, it simply works!

:hover hack is promised to work at least back in MSIE7.

This approach plays nicely with sticky menus (qTip did too, but as i understand additional code was necessary. In this case, panel sticks to the menu and remains there during all resizes and scrolls).

And, of course, all JS code inside panels now works as expected.

PS: The similar approach is successfully used on some popular resources like:

• aliexpress.com
• sacramento.aero/scas/
• hotline.ua

@esteewhy. wow. Amazing effort there, this post should really almost be filed as a separate issue: menu_minipanels version 3.x, or if not, at least a different module. The qtip dependency and complicated admin / configuration UIs and javascript files needed to configure / override the default styles have always been a pain point for a standard Drupal theming / dev process. I'd love to see a menu_minipanels v 7.x-3.x take this idea and run with it.

I just had a chance to review the code in comment #33 that seeks to strip out all dependence on qtip.

There is potential here to refactor the module quite a bit. This will potentially remove a lot of the code and extra hacks (particularly the D6 stuff where they had to process all the links in order to know to render the panels and JS configuration at the end of the page HTML with $closure.

However, the code in and of itself still needs work, because it produces invalid HTML. You actually hinted at this in your comment #33 Issue #1:

Although, rendered HTML looks fine, some JS gets in the way and adds some anomalies at least to a first menu item. In my case menu item A-tag was duplicated several times inside panel's nested DIV-tags.

.

What you're seeing is not JS getting in the way, but the browser working around the invalid code: you cannot place the entire mega menu inside the <a> tag, but if you placed it afterwards, it would work better.

Your invalid HTML:

<ul>
  <li>
    <a href="/somewhere">
      <span>Title</span>
      <div class="panels-panel"><!-- rest of mini-panel in here --></div>
    </a>
  </li>
</ul>

Valid HTML that would work:

<ul>
  <li>
    <a href="/somewhere">
      <span>Title</span>
    </a>
    <div class="panels-panel"><!-- rest of mini-panel in here --></div>
  </li>
</ul>

I think I've found a way to get the mini-panel to display outside the <a> tag, but needs a bit more work and testing. I'll see If i can look at this again tomorrow. But we really need to move this to a separate issue, which I can also do tomorrow.

I've moved the complete rewrite code idea off to a separate issue: #2215425: Menu Minipanels V2 without qtip.