There are a few reports of the latest version not generating output, and I this may duplicate of those reports.

menu_minipanels_preprocess_page_hidden() is not being called for us, so the $output is never generated. It looks like the bugfix for panels.css at http://drupal.org/node/991246#comment-3922420 requires changes to the theme being used in order for this module to work.

I couldn't get the menu_minipanels_preprocess_page_hidden() to be called despite trying to make the changes to the theme documented in the code, but I don't think this should be a requirement for this module to work.

The patch here just puts the output rendering back into hook_footer. It works for us in that we now see output generated, I think a full fix will need to find a different way to get panels.css to load. Perhaps even just with drupal_add_css(path to panels etc...) in hook_init.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

muhleder’s picture

Assigned: muhleder » Unassigned
Status: Active » Needs work
FileSize
459 bytes
muhleder’s picture

Actually, that patch is incorrect, was using the old implementation from v1.0 of the module. This should be correct using the mlid instead.

jippie1948’s picture

Thanks! I applied the patch and everything now works!

JP

aschiwi’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
876 bytes

This just made my whole week! Thanks @muhleder!

Since I couldn't apply the patch without manual work I am attaching a re-rolled patch to HEAD for the maintainer, which will also work for anyone who needs to patch 6.x-1.2 (I tested it).

Setting status to reviewed & tested by the community. I tested it on an existing site that had menu_minipanels 6.x-1.0 running before and also on a clean install.

madt’s picture

Patch from #4 worked for me. Thank you!

DeFr’s picture

Basically, this patch is backing out http://drupalcode.org/project/menu_minipanels.git/commitdiff/d946dfc7436... , this means that a full patch should look more like what I'm attaching.

I think it's needed, because right now, the module can't work for links that aren't in either the primary or secondary links, for example for core menu blocks: the blocks are only rendered in theme_blocks, which is called in template_preprocess_page, after menu_minipanels_preprocess_page_hidden is called. This means that their panels haven't been added to the list of panels for the page yet, and thus menu_minipanels_panels(NULL, NULL) doesn't find them.

Moving the code back to hook_footer makes sure that all the links in the page were hit, but has mentionned in the OP, there's still the bug commit d946dfc was trying to fix to address, which is adding Panels layout CSS to the page. Unfortunately, there's not a single CSS file that could be added in hook_init: each panel layout can have its own CSS, and we don't know the layouts the panels in the page will have before rendering them.

An alternative approach I'm going to explore might be to add the required CSS files in the footer, extracting the information when doing the render.

DeFr’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
3.84 KB

Ok, there you go: attached patch contains both the backout mentionned in #6, and the fix for the CSS issue. Instead of trying to register the preprocess handler before template_preprocess_page, the code now use the standard ordering, the preprocessing goes after the standard preprocessing, which means that all the blocks are rendered. Then, the styles are recomputed to account for CSS files added by panels.

Doing so, the hack to preprocess the links for the primary and secondary menu is no longer needed, so they're removed too. That should make the code as a whole more robust.

davemybes’s picture

#7 works nicely for us too. We had menus in a menublock that weren't being added, but now they're appearing. However, it seems to me we've lost the CSS from the panel layout. We have a 2 column layout, and before patching, the two columns were shown side by side, and I could see the CSS for the width. Now, the two columns are appearing one below the other, as no CSS is being applied to them. This is actually a good thing for us, as we need to make extensive changes anyway, so a clean start is better. However, its something to be aware of.

DeFr’s picture

@incrn8: Did you flush your theme registry after applying the patch ? Adding the panels CSS should be dealt with by the new preprocess_page.

davemybes’s picture

Yep, its been flushed a bunch of times already. I also applied your patch via Netbeans, using your attached file i.e. not by hand thereby possibly forgetting something :)

Its an odd problem, but not one I'm worried about, as our CSS guy is redesigning it anyway. I'm still kinda blown away by how simply your patch is. Nice work.

DamienMcKenna’s picture

I need to review this, it affects the D7 release too and might be a better way of handling it.

bmx269’s picture

I am having this issue in D7. Will this work for that version?

davemybes’s picture

No idea. Best is to just try ita and see. You'll have to figure out where to edit the code though.

bmx269’s picture

I will take a look. In the mean time I used the default menu blocks, and not the ones created with the Menu Block module for the minipanel menu. That works for now.

ledom’s picture

#7 works for me too, but CSS from panel is broken and I can't get two or more columns as expected from panel (like #8)

rlmumford’s picture

Has anyone got a patch that Fixes this for D7?

annikaC’s picture

D7 version would be absolutely amazing. I'm attempting it, but have a lack of experience with this kind of thing :(

vinoth.3v’s picture

Version: 6.x-1.2 » 7.x-1.x-dev

expecting patches for D7

DamienMcKenna’s picture

Status: Needs review » Needs work

This needs to be re-rolled against D6, it doesn't apply cleanly to the current codebase nor can I get it to work when manually applied due to how the module has changed in the past year. Furthermore, the current codebase works for me whereas this version doesn't.

DamienMcKenna’s picture

Status: Needs work » Closed (duplicate)

I'm going to mark this as a duplicate of #1199790: Support all menus because I believe it boils down to how the module was working on which menus to load. If the problem still exists, please re-open this issue and I'll take another look.

makbul_khan8’s picture

Title: Output not generated as menu_minipanels_preprocess_page_hidden not called. » applied patch for D6 but it doesn't work

applied patch for D6 but it doesn't work.
looking for correct patch or updated megamenu module.

Thanks

DamienMcKenna’s picture

Please update to the latest -dev version, I'll have a new RC version of it later today.