Multiple root categories
Preface
This is just a short tutorial aiming to help those, who wondered how to use the categoryi_menu module to achieve automatically updated menu items in two (or more) separate menu blocks.
The problem
It took me a while until I figured out how to fully use the capabilities category module, which are the prime goals of a containeri and which of a category. I admit, I still have gaps here, so I would like hereby to encourage anyone who feels experienced in this area to write a tutorial about this topic.
Coming over the initial frustration and learning which checkbox does what, I had to realize one thing: category.module (and all its extensions) was designed to have only one root menu from which all other menu items evolve. However, they may be situation where this is not appropriate, and one would like to have more than one menu block and still use the auto-update feature of category_menu. I hope that as a drupal user by now you know the difference between 'menu' and 'menu item'. Those are two term you should not mess while reading the following lines.
The solutions
Actually there are two solutions. The first is to let category_menu create all the menu items you'd like, and then move the menu items (let it be category or container) to the respective menu block of your choice. This might be a simple move using 'admin/menu', where you move a container and all of its child items get moved as well or a more complex one, where you will have to move several categories one-by-one. The latter is more the case when you use a hidden containeri - thus you don't have a central parenti item.
In my opinion though this is not the smartest solution. If you want to avoid the one-by-one operations, you should not forget to set the 'Default menu' under 'admin/settings/category' "Menu Item Settings".
Suppose you have to menu blocks: Menu_A and Menu_B. The process of adding containers and categories will be the following:
- Create the menu block Menu_A
- Create the menu block Menu_B
- Set the "Default Menu" in 'admin/settings/category' to be Menu_A
- create a HIDDEN container Container_A, do not forget to check the checkbox 'Menu items within this container'. Also remember, that you should not play with the 'Menu settings', when creating a category or a container. This will be handled by category_menu.
- create a category Category_A1, whose parent will be Container_A
- create another category Category_A1_1, whose parent will be Category_A1
- feel free to create other containers and categories. They all should appear under Menu_A, except Container_A which is a hidden container and thus there will be no menu item created for him. However, all of its direct child categories and containers will be displayed as 1st level menu items in Menu_A
Now let's move on to the second menu block. The procedure is similar
- Set the "Default Menu" in 'admin/settings/category' to be Menu_B
- Again, feel free to create the containers and categories. The menu items will be populated automatically and you don't have to move anything manually as in the case of the first solution.
Drawbacks
Although everything seems to be fine, there is no rose without thorns. Regrettably, this applies even here. If at any time you decide to edit a certain root category or container, its menu item will be relocated into the menu block, that is specified in 'admin/settings/category'. By "root" I refer to categories/containers which are directly listed (1st level) in the menu and do not have any visible menu items as parents.
In other terms, if you would like to edit Category_A1 in Menu_A, you should not forget to set the Default Menu again to Menu_A. Otherwise Category_A1's menu item will appear in Menu_B. At first I thought this was a bug, but considering the desing of the module, this behaviour is obvious. Moreover, Jeremy also confirmed this and was long aware of it. The sad thing is, according to his words:
there's no way to fix it that I can think of.
However, consider how meny times will you be editing a 1st level category or container. Many times while developing the site, but it will be really seldom in a production site.
Another interesting result
I accidentally deleted the top-level hidden containerii of a menu block just now and was intrigued to notice that the menu links of all the containers and categories below it didn't get scattered all over the admin/nav menu as usually happens.
So, at ../admin/settings/categoryi/Menu settings, I changed the default menu to the one whose hidden container got deleted, added a new hidden container, went to the orphans page, edited the top level container to make the new hidden container its parenti and all is well again.
..was intrigued to notice
..was intrigued to notice that the menu links of all the containeris and categories below it didn't get scattered all over the admin/nav menu as usually happens.
I was wrong. The menu items do get scattered.
Edit: The menu items do not get scattered *IF* you remember to set the default menu at ../admin/settings/categoryi to the one whose containers and categories you are deleting. And, this must be done *before* you delete.
They still land up on the orphans page, though. You can probably let them lie there. This is a lot better than deleting each scattered menu links individually at admin/menu, a guaranteed recipe for banging your head against the wall;-)
Update 2: Update 1 is what I get for jumping to conclusions. Although the menu links did not get scattered when the top level container was deleted, they did not disappear from the menu either, although they were visible on the orphans page along with their categories. And when I deleted the container containing the categories on the orphans page, the menu links got scattered again, so I had no choice but to individually delete each container and category. Back to square one:(
Default reassignment upon modification IS unseemly behavior
The behavior you describe in the next-to-last paragraph is fundamentally problematic for multilingual sites.
I'm setting up a multilingual, multilanguage site -- basically, I'm using Category Module to manage a tree structure on my site that is translated into Spanish, English and Portuguese -- create the categoryi once, translate each containeri/category and put each in the appropriate language block so that users in each language see the tree in their language with the appropriate descriptions, etc.
Setting this up can be time consuming -- you set up a multi-language block, then assign each language block into it.
Problems come when I need to edit the translated text for one of these categories or containers, or do any other modification to the category or container, for that matter (e.g. add a new content type that can be posted under the category, change the comment settings, menu display settings) -- the modified category gets re-located to the default menu.
This means that unless you get it perfectly the very first time, you're going to spend your life re-arranging menu items every time you tweak a variable. It's tedious for a single-language site... it's downright irksome for a multilanguage site.
I understand that the idea of category module is that it "automagically" creates menu items for your categories... but wouldn't it be possible to put a simple checkbox somewhere in the admin settings for the module, or else in each container's configuration, that tells Category Module to leave things where they are and not try to be smart?
I don't really understand the full plumbing of the code, but if someone could point me to where I could put a simple true/false check in the menu assignment code, I'd be happy to try it out on my site and see how it goes and let others know how this goes...
Great approach, but one problem
There is no way to make the menu blocks for the respective root categories to be visible all the way down to the actual node view when content is tagged with a categoryi in that respective root menu.
This would be easily possible if category_pathauto worked, but it is broken at the moment. Using only node ids, the breadcrumbs display fine (with appropriate settings in category_menu), but the menu doesn't work as it cannot reference an aliased path. And, it is impossible to add a hundred node ids in the block settings or keep shuttling between adding a node and adding its id to the block visibility settings.
I am sure there is a way to do this since the og module shows group specific menu blocks even without aliased paths (each organic group is a node), but I am missing the code. Of course, I haven't checked if the menu blocks are visible right down to the node view of a group's post.
Great tutorial, though. It solves the issue of putting containeri or category links in the primary links area, though in a roundabout way. I just wish I had paid more attention to this tutorial earlier.