Changes to container removes menu link from a custom menu

I have encountered the same problem. Thanks, Ramdak, for taking the time to document it.

And I have the same problem.

I have the same:

I added my containers to a new menu item (called ‘Content’, so the ‘parent item’ in ‘menu settings’ is ‘Content’) and configured them to ‘expand’.

If I then go to one of the container’s edit pages and ‘submit’ (no changes need be made) the container is moved to the ‘Primary Links’.

Interestingly, the value for ‘parent item’ displayed on the container’s edit page is still ‘Content’, as set. To change this, I click on the ‘edit the advanced settings’ link to get to ‘edit menu item’.

On that ‘edit menu item’ page, I see the Parent Item set as Primary Links and the ‘Expanded’ box unchecked. Here I reset them and all is well until the next time I ‘submit’ the container.

Screen grabs available if wanted.

On a different site, I’ve had a similar problem to Ramdak’s similar problem with ‘Programmes’. There a containers was first assigned to Primarly links but on ‘submit’ resets to the Administer menu.

I am using the category module for our new site: http://www.3ring.com/

So far the category module has been a great success. However, I am experiencing this same problem where I have manually moved some menu items to new menu blocks. These menu blocks contain items that are only relevant to the section of the site you are in. Everything works great except when you are editing the category page that is at the top of that particular menu blocks' menu tree -- it would always get relocated to the 'default' menu which is 'navigation'.

I have come up with a solution by hacking the category_menu module. Here is the diff (sorry not sure which version -- I think CVS from about 3 weeks ago):

Index: category_menu.module
===================================================================
--- category_menu.module	(revision 69)
+++ category_menu.module	(working copy)
@@ -516,7 +516,13 @@
   }
   $item['mid'] = $mid;
 
-  $pid = category_menu_get_mapping($parent);
+  // check if a menu item has been manually relocated and if so, keep existing parent
+  if (category_menu_get_mapping($parent) == 0 && $node->menu['pid']) {
+    $pid = $node->menu['pid'];
+  } else {
+    $pid = category_menu_get_mapping($parent);
+  }
+  
   $parent_path = 'node/'. $parent;
   if ($pid) {
     $item['pid'] = $pid;

If you can't apply the patch, then do this. Replace:

$pid = category_menu_get_mapping($parent);

...with:

  
  if (category_menu_get_mapping($parent) == 0 && $node->menu['pid']) {
    $pid = $node->menu['pid'];
  } else {
    $pid = category_menu_get_mapping($parent);
  }

I'd submit this as a patch but it won't work in all situations... but it does in mine. I think the desired logic would be as follows:

1. if the category has changed then allow normal category_menu behavior (i.e. move the menu item according to the category it is in)

2. if the category has not changed, keep the currently defined menu position

Does anyone know if there are plans to address this? Ideally it would be cool if you could associate a default menu block with a category/container.

One more thing- if you don't want to hack the category_menu module, you could take an alternate approach:

1. Create a new module with a nodeapi hook

2. Set the module weight to -1 so that it executes before the category_menu module (edit the systems table to do this)

3. In the 'update' operation of nodeapi, change the category_menu_default_menu variable to the menu block that you want to use

4. The result is that the menu item will just use the default setting (which you have cleverly set just before the category menu reads it)

I think this would work... I got partially down that path and then decided to hack the category_menu module instead.

Found a better way.

Ok, I reverted that little hack I did.

Instead, I put all the menu items in one block (i.e. the category module's native behaviour). Then I added some simple CSS:

#leftNavContainerTop li.collapsed {
  display: none;
  }

(#leftNavContainerTop is just the div ID I happen to be using)

This will hide all collapsed menus -- therefore, only the menu that is currently in context will be displayed because it is expanded. This, of course, assumes that you do not have your menus expanded by default. View the left navigation at 3ring.com to see what I mean.

Colin

OK guys, this problem is exactly how category_menu is designed to work, so technically it's not a bug. But clearly, the way the 'default menu' functionality is behaving at the moment is not desirable in many situations. I'm going to be working on a solution that will get around this and other problems in category_menu - not sure exactly how it's going to work yet.