Breadcrumbs error with disabled menu item

Erm, I can repeat this. But wait a minute, if you enable the menu item you get your expected result. I would expect the breadcrumb to follow what you told it to do, be disabled and it does just that.

Sorry, I don't believe this to be a bug. It's doing what it's been told to do, be disabled.

I think what you are trying to do here is use the menu system to manage your breadcrumb and what you probably ought to be doing is using taxonomy and the taxonomy_breadcrumb module to achieve your desired results.

regards,
--AjK

I agree that the item's behaviour (when it's disabled) is correct for that particular item itself, but it shouldn't be affecting other items. When it's disabled, it also disables part of the functionality attributed to the parent item, even if the parent item is enabled. I don't see this as the correct behaviour. The parent item should still show up as a breadcrumb when enabled.

To get back to the example, if menu3 is disabled, then it (and its children) shouldn't show up in the menu listing or the breadcrumbs. menu2, on the other hand, is enabled so it should show up in the menu listing and in the breadcrumbs.

Hopefully that makes some sense. I'm setting this back to being a bug. Please enlighten me if I've missed something here.

Just out of interest, if disabling a menu item removes the link from the menu structure and the location of the page in the tree, what is it actually used for? Is it merely a temporary way of deleting a menu item? Permissions should control visibility for those roles that shouldn't see the link.

I see the logic of using it to create a site hierarchy. Disabling the menu item would then allow the site structure to remain intact. OF course, it would only really work for the last child pages in the tree, otherwise there would be a missing step.

I dont think that this is a bug in the module, more of a feature request, although I am reluctant to change it without the approval of others. Perhaps the request could be for another option for each menu item to hide the menu term but display the breadcrumb, similar to the category module.

Is taxonomy really a better way of defining a site hierarchy - this would seem to be the fundamental role of the menu module?

My understanding is the same as yours, and follows the logic. I don't think it's a permissions issue because the (in)visibility is global. I'm interested in this issue because a client doesn't want an item to show up in the menu, but wants the parent item in the breadcrumbs. After studying this, it seems like the parent item not showing up in the breadcrumbs is a defect because it (the parent item) is enabled.

I don't see taxonomy as the way to go here because I see that system as a way to maintain "is a" relationships, like in OO speak, while the menu system is for "has a" relationships. For example, the home page of drupal.org has a Forum section, the Forum section isn't a "Home".

I think adding options to separate the menu item from the breadcrumb would definitely be a feature request. In any case, here's a patch for this thing. If it's felt that this should be something other than a bug, so be it. Even though it's wrong. ;)

I'm moving this up to CVS so that it gets some attention. Should it be a bug, or a feature?

Moved out of the "x.y.z" queue to a real queue.

6-dev uses a new menu system. So, this will have to be fixed in 5 and backported if need be.

-K

Confirmed this is not a problem in 6.x and does still exist in 5.x.

This solution looks overly complex and does not use our coding standards. The biggest coding standards problem is using and instead of &&. For more, see http://drupal.org/coding-standards.

The problem is we unconditionally pop off the last item at the end of menu_get_active_breadcrumb() to make sure the current page is not included. However, if the current page's menu item is disabled, such as this case, the parent disappears.

I think the best solution would be to pop the current menu item off of $trail, before the breadcrumb link construction.

Here is an updated version of the patch to conform with the coding standards.

Tested on Drupal 5.7

Even with this updated patch, it should be considered that the patch changes the default behavior. Some sites may have worked around this broken behavior, and updating it will annoy some people.

Just marking this for review.

http://drupal.org/node/244725 is the same issue. I think it might be better since it is designed to handle disabled items anywhere in the menu tree, not just the end of the breadcrumb.