bdragon, I can definitely help you with testing this out.

Venkat

That's good to hear.

I also have another person to help test lined up, so I think I'm going to go ahead with the initial implementation.

I've been doing some general cleanup in preperation for this.

I think the first order of business is to add some logic to category.module to determine the changes made to a node (category x added, category y removed, classification changed from x to y, etc.) Having a central piece of logic for determining this should make it easier to have less buggy logic in the modules that need to know this kind of information. Stuff that "tracks" changes like category_menu will have a *much* easier time doing their job.

This sounds great to me.

I only use Category menus for breadcrumbs.

I might be able to help test.

How would it affect existing entries in the menu table, if at all?

Thanks for tackling this!

Kristi
(a huge fan of Category module)

The lack of proper integration with TAC is a show-stopper for me.
I tested this very carefully but could not get TAC to limit access to taxonomy

I need different containers to propagate their own menus. Having all the categories under all of my containers dump into the same menu causes a huge problem. It largely prevents me from using the menu for anything useful.

Just found this Issue - sounds really great!

I disabled the existing category_menu module completely on my site, some time ago (after months of struggle with menus), because I was unable to talk even the other admins of the site into dealing with strange duplicate/self changing menu items, and into *NOT* filling the menu options on node-forms (even included a warning in bold letters into localized help on that form-item, but no luck). Since that, I add menu items manually, which is not that bad, considering that we create new ones "once a year" or so. The #4 (if I understand correctly) is therefore a must, if I want to use the module again.

Functionality-wise, much more of an issue for me is the Breadcrumb. Possibly it's one of the biggest problems of Drupal generally, when it comes to users' navigation experience.

I would like to see the Breadcrumb generated to node-level just like Taxonomy_breadcrumb module does, i.e. while viewing a node with Category2 assigned, the Breadcrumb would show for example "Home » Container » Category1 » Category2" or something like that. This'll allow the user to use Breadcrumb for its real purpose, i.e. keeping track of "where I am", and easily navigating back to any level of the tree (in a simple config at least), no matter if there are menu items enabled for current container/categories or not. This is much more efficient for some scenarios of browsing, than to have a Navigation menu open, with full lists of all the Category names (or even nodes) down the tree. On large sites, such a menu becomes longer than the viewed node, and user finds it easier to go back to the top container via primary links and then down again Category by Category (on our page), than to scan that enormous menu for parent categories he wishes to return to. I'm inclined to omit large Category-trees from menu at all, for this reason. User sees the tree on Container page with more comfort, and then he would be able to move back and forth via Breadcrumb, just like if browsing directories of a filesystem. Given that the Breadcrumb doesn't vanish (or change to just "Home") once a node is reached...

It should work just like Taxonomy_breadcrumb - just set the breadcrumb on page, without generating any items to the Menu system. If the module puts an item (even disabled one) to my menus for every single node, then I'll remove the module for sure - thousands of menu-entries, that's a nightmare. Imagine, that I like to have also a few of *MY OWN* menu items, to be managed manually, between all this flood. No way. I want menus for things like Log out, My account, Aggregator, plus a few containers and categories, and no more - but without loosing the Breadcrumb, which is a completely different kind of navigation in users' eyes.

It doesn't matter to me, if the breadcrumb finally shows other "path up", where multiple Categories are assigned to a node. Just grab any path to the root, and I'll be happy. For most sites this would be enough, I believe.

I would be really happy to see such Breadcrumbs in the new category_menu module, or elsewhere in the Category package.

Thanks for all your great work.

Oops, I'm sorry, got a bit lost in the Issue queue... My wish is already discussed here: http://drupal.org/node/75276 - I just added a comment with my version of the solution to that thread.

Hello - I have steered clear of category.module because of tales of woe on some threads, but regardless I think it should be renamed (or 'Categories' inside core should be reverted to 'taxonomies') because the confusion caused is endless. I estimate that the co-existence of the two uses of of the word category waste 1-5 days of new users time. Perhaps it could be renamed to describe what it does.

Another thing that's needed with all these conflicting choices is functionality descriptions that describe why one would choose a module that replaces core functionality over the core: - What functions does it replace? What commonly used modules is it an alternative for? What extra functionality does it bring or make easier to achieve?

In fact all modules could do with that structure of information!

Good luck
Zaph

I agree with Zaph on the naming. It's just too close and does nothing for the project that the name is not distinct.

One thing I have wanted for a long time is the ability to use this module, but to get the "old book-style" menus back. Either that or a new navigation menu that is similar and can live on the sidebar. I use this module on a daily basis but I long for those book style nav menus to make it easier to jump around the content of a large container.

I'll check in on the progress of v6 and hope to help test things out.

Thanks!