Site logo replaced with Menu Minipanels enabled

Thanks, this is interesting. I noticed this once in my development environment, but didn't associate the issue to menu_minpanels.

I'll look into it now.

Same problem here, when Menu Minipanels is enabled my site logo gets replaced with just the name of the site (so no picture, just text). This is caused because enabling the module sets the src of the logo to just 'logo.png', instead of the full path to the logo.

So it changes this:

<div id="header">
     <div id="logo-floater">
        <h1><a title="site" href="/"><img id="logo" alt="site" src="/themes/garland/logo.png">
        <span>site</span></a></h1>        
     </div>                                                  
</div>

to this:

<div id="header">
      <div id="logo-floater">
        <h1><a title="site" href="/"><img id="logo" alt="site" src="//logo.png">
        <span>site</span></a></h1>    
      </div>    
</div>

I actually looked into this problem, but could not find a solution.

Edit
After some more testing and trying I found out that this module actually completely overrides the theme settings, even if you set the sites name, logo and slogan off in the themes settings, they are still displayed. When you turn the module off, the name, logo and slogan disappears (if you set this in the theme settings).

I searched on to fix this problem, I finally came across something that causes this strange behavior. These lines are responsible for overriding the theme settings:

  $primary_links = theme_get_setting('toggle_primary_links') ? menu_primary_links() : array();
  menu_minipanels_preprocess_links_at_init($primary_links);
  $secondary_links = theme_get_setting('toggle_secondary_links') ? menu_secondary_links() : array();
  menu_minipanels_preprocess_links_at_init($secondary_links);

If you comment these lines out (for testing purposes) everything works fine (right logo is displayed, etc.). I know that just throwing these lines away isn't a good thing to do, so I will try to think about a nicer solution.

Edit 2 (DONE?!)
Well, after some hours of reading through code and trying things...I think I may have the solution!
On the earlier mentioned lines

  $primary_links = theme_get_setting('toggle_primary_links') ? menu_primary_links() : array();
  menu_minipanels_preprocess_links_at_init($primary_links);
  $secondary_links = theme_get_setting('toggle_secondary_links') ? menu_secondary_links() : array();
  menu_minipanels_preprocess_links_at_init($secondary_links);

the 'theme_get_setting()' method is used, this method overrides the changes in the theme setting. It is better to use theme_get_settings() (mention the S and the end) instead. This method retrieves all the theme settings.
So change the earlier mentioned lines to:

  $_links = theme_get_settings();
   menu_minipanels_preprocess_links_at_init($_links['primary_links']);
   menu_minipanels_preprocess_links_at_init($_links['secondary_links']);

At this point you must also change the menu_minipanels_preprocess_links_at_init() function because there is a foreach loop in it and thus this function requires an array. But were not giving this function any array anymore, so remove the foreach loop! You must get this:

function menu_minipanels_preprocess_links_at_init($links) {
    if (!empty($link['minipanel'])) {
      $prefix = '';
      if (!empty($link['attributes']['class'])) {
        $prefix = $link['attributes']['class'] . ' ';
      }
      $link['attributes']['class'] = $prefix . _menu_minipanels_include($link['minipanel'], $link['menu_minipanels_hover']);
    }
}

It should now be fixed, I did test it and honestly it works for me. I don't know how to create patches, so I tell it you this way. I don't know if any problem will arise after this change, but I didn't see one.

Subscribing

Thanks @Robert_W, great work narrowing down the issue.

I'll be fixing this in the next dev release.

the patch in #3 breaks the javascript effect of menu mini panel on my site ???
without patch I confirm the problem with the logo ... and theme

There look to be a few issues with the patch in #3. I've just got my own patch working that also fixes the JS / JQuery issues. I've got to tidy up the code a bit, and it will be a bit hacky, but I'll post it in a bit anyways.

Hi #willieseabrook nice module. I think I have patched this issue. But if anyone can test that would be good.

I've adjusted the first issue mentioned in #3. It needed to call the menu_primary_link() function. It was just passing in 1 or 0 not any actual links.

  $_links = theme_get_settings();

  $primary_links = $_links['primary_links'] ? menu_primary_links() : array();
  menu_minipanels_preprocess_links_at_init($primary_links);
  
  $secondary_links = $_links['primary_links'] ? menu_secondary_links() : array();
  menu_minipanels_preprocess_links_at_init($secondary_links);

 

There was no need to change the second block of code mentioned in #3, and it didn't do anything anyway as $links was passed into the function but $link was called. I guess you got lucky #Robert_W. I did manage to get your patch to work at first but I think it relied on certain aspects of the old code being cached, but not really sure?

I've added some code to hack the Drupal_add_js function on lines 301 - 302 and 331 - 333. Basically it was being called twice per minipanel menu item. This appeared to be creating arrays for items like event => [mouseover, mouseover] in the settings for Qtip. As it was expecting strings e.g. event => mouseover, it caused JavaScript to break. Code below:

  // This is a hack to prevent drupal_add_js from being called more than once per minipanel_name 
  // This sets the counter variables dynamically

  static  $menu_minipanels_drupal_add_js_count = array();
  eval('$menu_minipanels_drupal_add_js_count['.$minipanel_name.'] = 0');

  // End of hack
  // Second part of hack below

  // Second part of drupal_add_js hack, checks counter variables
  
  if( $menu_minipanels_drupal_add_js_count[$minipanel_name] == 0){
    drupal_add_js($settings, 'setting');
    $menu_minipanels_drupal_add_js_count[$minipanel_name]++;
  }

  // End of hack

Sorry it is a bit hacky, I'm not good with jQuery yet, but the patch should help until the module can be properly fixed.

Needs review

parse error
the eval
eval('$menu_minipanels_drupal_add_js_count['.$minipanel_name.'] = 0');
must be
eval('$menu_minipanels_drupal_add_js_count['.$minipanel_name.'] = 0 ; ');

Thanks, did it work for you when you fixed this?

Just tested this and it still works for me as the variable I initialise with the eval gets assigned and initialised automatically in the second bit of code again anyway.

So it didn't matter for me that the eval didn't parse (I guess my server is less strict on that as it didn't even give an error). I've fixed the eval line and left it in as it makes what the patch is doing clearer.

My eval code still isn't parsing so I have removed it as indicated above.

A repost from a closed (duplicate) issue:
@sammo: The patch at http://drupal.org/node/948784#comment-3836822 worked. Thanks.

In my case, the patch for this issue: $options[check_plain($panel_mini->name)] = check_plain($panel_mini->display->title); instead of the original: ($panel_mini->title); still resulted in an empty select box. However, when I used ($panel_mini->admin_title); I got to select a minipanel.

I guess I am doing something incorrect, but when I create a minipanel by adding content menu--> primary links, I still get WSOD. How are you using primary links?

Hi @ talatnat maybe we are not on the same page. I've attached a screen grab of menu minipanels working with primary links for me. I'm not getting a WSOD when I set this up.

yes it works for me whith eval fixed

@sammo: Hi. Thanks, I "finally" got it working -- one of the primary links from a previous version was still enabled, and was causing some kind of WSOD recursion.
Two things: 1) Not sure if it is related to the second bit of code in the patch, but the minipanel appears twice, one above the other. I'll check if the patch got added correctly, or if its because of my styling 2) I still require admin_title to see the select box.

Added: a) I got parse error for the original eval function, but the minipanel shows twice: eval('$menu_minipanels_drupal_add_js_count['.$minipanel_name.'] = 0 ');
b) If, I switch to pixelpreview's eval, I don't get a parse error, but the minipanel does not display at all.
c) If I remove the second part of the drupal_add_js hack, I don't get a minipanel menu displaying. Adding it back, gives me the double panel (although I still don't know if this is related to the minipanel name being called twice).

Added clarification: Re: "the minipanel shows twice". Actually, there is one large minipanel, but the minipanel's content is duplicated twice inside, one above the other.

I got it also working with all the patches proposed above with the same result as in #18 by Talatnat: "There is one large minipanel, but the minipanel's content is duplicated twice inside, one above the other."

@jippie1948 Hi not sure what would be doing that. I could be a styling thing. Try inspecting with firebug. I'm not too convinced about this module anyways. There are some issues with it as far as search engine optimisation is concerned. I was going to give http://drupal.org/project/megamenu a go, as I have seen some nice implementations.

Also make sure you have the up to date versions of jquery_ui etc..

Same issue on a customized Fusion subtheme. I haven't yet look closer into it as the 'menu_minipanels' module also breaks lots of other Fusion styles.

Can anyone else confirm these major compatibility issues with Fusion?

Edit: Located #954582: Compatibility with Fusion Theme confirmed which recursively points back to this issue ;)

Thanks @gjerdery and for your great diagnosis work @Robert_W.

Something was indeed going on with the theme_get_setting call. Haven't used your patch here, but did use theme_get_settings (plural). Your diagnosis saved me loads of time fixing this.

Committed to dev.