Let generated menu items be disabled on creation

When I click on an assigned node from a category page, I expect that the breadcrumb to the assigned node will appear automatically. At present this does not seem to happen, unless "Show links to categories on assigned nodes" is checked in the Category display settings of the container and the assigned node has been created since "Show links to categories on assigned nodes" has been checked.

I would expect that the breadcrumb should appear even when "Show links to categories on assigned nodes" has not been checked and should appear for nodes regardless of when they are created.

I also notice that when "Show links to categories on assigned nodes" is unchecked, the menu items for the assigned nodes do not disappear, as I would expect them to. Even when the category to which a node is assigned is changed, the menu item for the assigned node appears under its new category menu item. This suggests it's not a caching issue. (In fact I have caching turned off, so I think it shouldn't be anyway.)

The bug originally reported here was to do with the problem reported in http://drupal.org/node/43160, which has now been fixed.

The "Show links to categories on assigned nodes" setting only affects display of links on assigned nodes. It does not affect menu items or breadcrumbs for assigned nodes: these are controlled by the "Menu items for assigned nodes" setting.

Perhaps it's a conceptual error on my part, but I would like to be able to have a breadcrumb to an assigned node without a menu item for that assigned node appearing in the navigation menu. It's doesn't seem like this is possible at present -- is that right?

I can't be sure at the moment, as I've just upgraded to the latest CVS version of category (rev 1.52), and now whenever I try to change any category or contatiner information, I get a blank page when I hit submit and the changes don't always seem to take effect. I notice that the category_display.myqsl and category_menu.mysql files have disappeared, and I'm wondering if I need to update my database. Could this be the case?

Just realised that I forgot to mention that I am running the 4.7.0beta3 version of drupal, not the latest CVS version. Perhaps I should be doing so with the category module?

Now I'm using drupal cvs, category is working again, and I've realised I've been talking rubbish for many of the posts in this bug. However, I now think I can now describe accurately what I regard the bug to be. I've also taken the liberty of reopening it -- I'm not sure of drupal etiquette so I hope this is OK. Anyway, here goes:

I expect that all nodes that have been assigned to a category should have a breadcrumb path, regardless of any other settings.

At the moment, a node assigned to a category only has a sensible breadcrumb path through the category hierarchy if "menu items for assigned nodes" is checked when the node is assigned a new category.

I regard this linkage between menu items for assigned nodes and breadcrumbs as a bug, but am open to being convinced it's a bug in my thinking.

egfrith: this is not a bug, this is how it's supposed to work. The category module (and specifically category_menu) is designed to rely on menu items for its navigational aids and for its breadcrumbs. This is different to book, taxonomy, and most other existing Drupal modules, which do not rely on menu items, but instead rely on manually setting the breadcrumb for each page (by using menu_set_location()), and on manually generating navigational aids.

The idea is that if a user doesn't want menu items (and all the things that come with it, e.g. breadcrumbs), he/she doesn't have to have them, and can choose whether or not they're generated on a per-container basis.

Your question was quite valid, and it's great that you managed to communicate it fluently in the end. It's quite OK in Drupal etiquette to re-open issues if you feel that they haven't yet been resolved.

Hello,

I'd like to use breadcrumbs with categories but not to have similar menu sturctures for navigation. My solution is to let category system to generate menu items for a pre-set menu, but not to have that menu as a visible block. Then I make manually separate menu structures for the navigation purposes. This works as long as there are not too many navigation items to be updated manually.

Br,
Juha

OK, I think the best solution to this problem is to let menu items be disabled when they're generated by category_menu. I'll work on adding this as an option to the category_menu interface.

This sounds like a workable solution, and looks like it would let me organise breadcrumbs the way I'd like. However, if you add the feature the way I understand you're going to, there will be an additional option in "Category menu items". Users will be invited to create "menu items for assigned nodes" and then disable them straightaway, which feels a bit strange to me.

I've a suggestion to keep the configuration simple and to make the default option in line with what the people posting on this bug/feature seem to think:

1. Create menu items for assigned nodes automatically (and get rid of the "Create menu items for assigned nodes") option.
2. Make the new option "Enable menu items for assigned nodes"

This keeps the number of options the same as now. The only disadvantage is the number of menu items that have to be stored, but I suppose this isn't very much data.

This feature has been committed to HEAD, and appears to be working fine. The two check boxes, 'menu items within this container' and 'menu items for assigned nodes', have been changed to lists of radio buttons. Each radio-button list has three options: 'disabled', 'enabled', and 'enabled (but disable each menu item)'. The third option invokes the new functionality, and results in breadcrumbs being visible, but not the actual menu items.

Usability feedback on this setup is welcome. This seemed the easiest and most intuitive way to do it for me, but others may have different opinions. Also, this change requires no database upgrade - it will work fine with your existing category_menu schema and data.

Thanks very much for the work Jaza - category now lets me acheive the effect I'd like of breadcrumbs but no visible menu entries for assigned nodes.

However, I have got a comment on the UI:

I find the terminology "Enabled (but disable each item)" by one of the radio buttons in "Menu items within this container" and "Menu items for assigned nodes" rather confusing. How can you enable and disable something at the same time? I think that emphasising the creation aspect would go some way to improving this: e.g. "Disabled" -> "Don't create" and "Enabled (but disable each item)" -> "Create (but disable item on creation)".

I am still wondering whether you should give a "disable" (or "don't create") option at all, as to have a sensible breadcrumb, a node seems to need a menu item. Since leading web experts ;-) argue that "breadcrumbs should be displayed on every single page of the site without fail, reflecting a page's position in this hierarchy" (Epstein, 2005, http://www.greenash.net.au/posts/thoughts/basic_breadcrumbs_and_taxonomy), it would seem that breadcrumbs (and hence menu items) should be mandatory. This would allow you to get rid of one option, and I suppose you wouldn't have to change the database either (though then there would be redundant information there). If you don't want to remove the "disable" options, I would suggest the current "Enabled (but disable each item)" as the default setting.

There's one more point. Suppose I have created but disabled menu items for assigned nodes, then created 100 nodes, and then suddendly decide I want to enable menu items for those nodes. I click on "Enabled" in the container settings, and expect all the assigned nodes to have menu items. They don't. I look at the help text "For assigned nodes, these settings affect new and existing nodes" and think "hang on!", and can find no way of fixing it apart from going to administer->menus and enabling 100 items individually (yawn). I would like to be able to change the behaviour of all of the menu items (existing and not-yet-existing) at once using these settings. But I'm willing to be convinced that there is a good reason for the current setup of making the settings apply only to items that have yet to be created.

I was hoping to update my test site last night with this to have a look, but never got time.

However, from what I've read here: definately a useful revision but have to agree on the wording.

I would have to agree that "enable(disable)" just doesn't sit right.
rather than mixing assertions, can we have a positive, but conditional, assertion, namely:
"enable (for breadcrumbs only)"
or in egfrith's version:
"create (for use with breadcrumbs only)"

On the need for 'disable', I think there would be occassions where categories are created that do not use menus or breadcrumbs. As well as the usual 'navigational' categories, you could assign secondry categories to a node, most obvious reason I can think of is for access restrictions but I'm sure there are others. The 'navigational container' will be 'heavier' (or is that lighter) and so breadcrumbs will reflect this container and others need not bother. Of course if the option was removed then for these secondry containers you would just select "enable (for breadcrumbs only)", the resulting menu path just wouldn't appear anywhere (is there any great overhead in creating a menu path that is not used?).

Scott