Hi,

we've been noticing some bugs when using this module with panels_everywhere. When the theme cache is cleared the menu_minipanels_preprocess_links_at_init() call from hook_init is calling a theme function to generate a panel, which is having the effect of setting an empty cache registry.

We are also seeing a similar problem with calling menu_primary_links() from hook_init. If the 'Cache tables' are cleared then we again get an empty cache registry.

We seem to be able to fix the problems we are seeing by moving the logic code from hook_init to hook_footer. Do you know if moving the code to hook_footer might cause problems? There are several reported problems with accessing theme functions from within hook_init.

eg.
http://drupal.org/node/219910
http://drupal.org/node/681358
http://drupal.org/node/405578

Thanks,

Mark

CommentFileSizeAuthor
#6 menu_minipanels-cache-clear-breaks-theme.991246.patch1.97 KBmuhleder

Comments

willieseabrook’s picture

willieseabrook commented
Assigned: Unassigned » willieseabrook
Status: Active » Needs review

Thanks for the great spotting @muhleder. I've committed changes to dev that should fix that. The code that actually renders the minipanel making the theme calls, is delayed and not called until the footer.

However, I can't test your particular environment. If you could upgrade to dev on your test environment and let me know if it fixes the issues you've been experiencing.

Please note that the latest code will break your menu_minipanels. It's easy to fix though, you just need to edit and save each menu item that has a menu minipanel attached. You dont need to make any config changes, simply clicking the save button that will call a submit function and set a variable correctly.

muhleder’s picture

muhleder commented

Hiya, thanks for the fix! We'd actually patched the copy in our environment, and it seemed to be working well in testing, but we have another issue reported to fix. I'll try the new dev version and see if it works for us. Might write an update hook to update the menu variable as well.

Cheers,

Mark

willieseabrook’s picture

willieseabrook commented

Menu minipanels now depends on the mlid to determine which menu item uses which qtip settings and which minipanel.

The mlid is set in the _submit hook when the menu item is saved. So the update hook will need to loop through each menu item in db and adjust the options array (or simulate a submit which will do the same thing).

And note I mean the 1.1 version, not dev. Accidently committed everything to root branch so had to do 1.1 release rather than dev release.

That said, 1.1 eliminates all the known bugs and is thus a lot more stable.

willieseabrook’s picture

willieseabrook commented

Moving the minipanel rendering actually introduced a bug. because they were being rendered in hook_footer, that was *after* css had already been added to the page variables, so panels css was not being added to the page, breaking panels layouts.

Fixed by adding a preprocess hook using theme_registry_alter to come before template_preprocess.

ianchan’s picture

ianchan commented

subscribe

muhleder’s picture

muhleder commented
StatusFileSize
new menu_minipanels-cache-clear-breaks-theme.991246.patch1.97 KB

The latest version looks pretty good, and glad to see the custom menu target is working now as well. We are using panels as well as the minipanels, so I guess we'd have panels css loaded on every page anyway, which explains why we didn't see the bug in #4.

We did have one more fix which isn't included yet. When we clear cache (using the admin_menu via devel, but also other cache clear calls as well I think), we were seeing a broken theme registry. I tracked this down to the $theme_settings block in hook_init().

The attached patch moves this to hook_footer() as well, which has been working for us over the past month. This is with a fusion based theme fwiw, but I think we would see the behaviour with any theme from memory.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Status: Needs review » Fixed

Please use the latest version this problem is fixed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.