Breadcrumbs are only taken from one menu

hmm, there is also a problem with breadcrumbs

Subscribing. I agree with #4 -- the first thing I like to do is split up that long menu array into logical sections and put each into its own block -- one for admin menu items, one for user account administration, and a third for 'navigation' so that 'navigation' only contains non-admin navigation items. And it keeps all that admin stuff from showing up in the menu selector on the node page.

Having the admin menu in a separate block that defaults to showing up in the left column (or maybe even the footer) out of the box also seems like it helps address the confusion in usability studies about where to find the admin area, by giving it its own spot.

We experienced Drupal users know that all those admin items aren't going to show up to non-authorized users, but new Drupal admins don't, so placing all that admin stuff in the main navigation is doubly confusing. By placing it in a separate block it's easy to understand that you can show/hide that information differently for different audiences.

I'm sure this isn't easy to do, but you can do it in the UI, so there must be some way to do it automatically.

If I understand all this correctly what we are trying to do is allow modules to specify "menu blocks" (called "menus" in admin settings), and allow hook_menu's items to specify one of these blocks (defaulting to navigation if it doesn't exist). Here's a straw man of how the api might look:

function hook_menu_block() {
  $blocks = array();
  $blocks['default'] = array(
    'title' => 'Navigation',
    'description' => 'The default menu block.',
    'block settings' => array(
      'enabled' => true,
      'default region' => 'left'
    ),
  );
  $blocks['admin'] = array(
    'title' => 'Site Administration',
    'description' => 'The admin menu block.',
    'block settings' => array(
      'enabled' => true,
      'weight' => -1,
      'default region' => 'left'
    ),
  
  );
  return $blocks;
}

function hook_menu() {
  $items = array();
  $items['admin'] = array(
    'page callback' => 'admin_page',
    // references "blocks['admin'] -- all children menu items would inherit this setting, unless otherwise noted
    'menu block' => 'admin'
  );
  return $items;
}

I don't think we were talking about letting modules specify them (hadn't thought about that) but to have a different arrangement in core, out of the box, to make it easier for people who are new to Drupal.

Well, it seems like allowing any module to create its own menu block would be a big win (as well as solve this issue). Core, and to a much greater extent, third party modules' usability would be improved if they could send their by default somewhere other than the great menu barf bucket (a.k.a. navigation menu). I'm forced to hide that monster on every drupal site I do, and I don't think i'm the only one.

While I'll suffice for adding a few extra lines in an install file to accomplish this goal, I think this issue is really about giving menu items options beyond the menu barf bucket. I'll do a bit of research into how much I'm underestimating the scope of that change.

@Nick Lews - creating menus and blocks is pretty trivial, but one problem is for various themes a particular region may not be available to activate it into. Right now there would just be DB calls, so a thin API would be helpful. The problem remains with the breadcrumb, though there are is an issue or two open to try to address this - basically you might need to specify a hierarchy of menus (i.e. collections of menu leinks) to look at to find a non-empty BC, though his might have some performance implications.i

(xx) deleted

(xx) deleted

breadcrumb problem: I use this module to fix breadcrumbs http://drupal.org/project/menu_breadcrumb.
#258361: Include Menu Breadcrumb in Drupal core

and there was a patch with similar functionality (but it did not make it into core): #170309-25: Regression: Breadcrumb doesn't always include all active items

+1

This way we could get rid of the horrible label "Navigation" for a menu as well (see #273137: Split Navigation to User and Administration menu and http://groups.drupal.org/node/14755#comment-50810).

(BTW it always feels wrong an issue which to me is a plain usability bug is tagged "feature request".)

right, I think this could be done in contrib for D6 (give me a little time and I'll give you sample code) so it's partly a question of how much *needs* to be in core, and how much, if any, UI to provide.

ok, here's the D6 contrib module: multi_bc.

I'm just going to paste is here - too short to need an attachment. I did some quick testing by moving the sole copy of the subtree with the root link pointing to ?q=admin to various menus/

multi_bc.info

; $Id$
name = "Multi-breadcrumb module"
description = "When navigation is not enough. Tries to find a link for the current pag in any menu to keep the breadcrumbs more meaningful."
package = "Administration"
core = 6.x
dependencies[] = menu

multi_bc.module

/**
 * @file
 * Find any menu containing a link for the current page to get a better active trail. 
 */

/**
 * Implementation of hook_init().
 *
 */
function multi_bc_init() {
  // This is mostly copied from menu_tree_page_data().
  $item = menu_get_item();
  if ($item['access']) {
    $list = menu_list_system_menus();
    $result = db_query("SELECT menu_name FROM {menu_custom} WHERE menu_name NOT IN (". db_placeholders($list, 'varchar') .")", $list);
    While ($a = db_fetch_array($result)) {
      $list[] = $a['menu_name'];
    }
    // todo for multi_bc: sort these menu names based on some weight from the UI.
    foreach ($list as $menu_name) {
      // Check whether a menu link exists that corresponds to the current path.
      $args = array($menu_name, $item['href']);
      $placeholders = "'%s'";
      if (drupal_is_front_page()) {
        $args[] = '<front>';
        $placeholders .= ", '%s'";
      }
      $parents = db_fetch_array(db_query("SELECT p1, p2, p3, p4, p5, p6, p7, p8 FROM {menu_links} WHERE menu_name = '%s' AND link_path IN (". $placeholders .")", $args));
  
      if (empty($parents)) {
        // If no link exists, we may be on a local task that's not in the links.
        // TODO (core): Handle the case like a local task on a specific node in the menu.
        $parents = db_fetch_array(db_query("SELECT p1, p2, p3, p4, p5, p6, p7, p8 FROM {menu_links} WHERE menu_name = '%s' AND link_path = '%s'", $menu_name, $item['tab_root']));
      }
      // End of stuff copied from core - here's the new code:
      if (!empty($parents)) {
        menu_set_active_menu_name($menu_name);
        return;
      }
    }
  }
}

@pwolanin: i think, the menu_breadcrumb module should do the same

can you check the corresponding code in the menu_breadcrumb_init()

    $menu_item = menu_get_item();
    $menu_link = menu_link_load(db_result(db_query("SELECT mlid FROM {menu_links} WHERE link_path = '%s'", $menu_item['href'])));
    $use_menu = $menu_link['menu_name'];
    menu_set_active_menu_name($use_menu);

thanks

@Pasqualle - that is similar, but fundamentally wrong. Links ARE NOT UNIQUE. Hence, the result of the query in #19 does not specify a single link, and the result of the query may change if you add links to other menus. I think I commented on an issue about that module. Its broken query causes problems when used with admin_menu.

My code above could be made simpler - since we don't actually need to select the parents. Also, there is a TODO about weighting/ordering the menus. But that's the key peice - you have a defined, consistent list of menu names to walk through and query.

Breadcrumbs in D5 were far from perfect but in D6 they seem to have taken a step backwards. The problem seems to be that the Navigation menu is the only active menu and therefore is the only one that generates the breadcrumb trail.

I've been using the same technique as KarenS where I like to separate the menus items into intuitive groups: admin, user, site navigation.

I also use simplemenu which allows setting the specific menu to use in the simplemenu so I sometimes create a menu called Simplemenu to control which menu items appear in the dropdown (usually just for admin paths or shortcuts for the admin role). Moving the Administer menu tree out of the Navigation menu causes breadcrumbs to be lost therefore D6 forces us to put all menu items that require a breadcrumb into the Navigation menu.

This restriction could be used as a site building technique where placing site navigation items into this menu would generate breadcrumbs, we could hide this menu from view and construct separate menus to hold our user visible menus (seems like a lot of manual work for something that should be a given).

If breadcrumbs were generated for all menus then this could possibly cause an issue if the same path appeared in another menu. I think what we need here is the ability to define which menus generate breadcrumbs. Is this technically possible?

On the separation of menus in D7: I think it's very important to have a separate menu for each type of menu item (admin, user, site navigation) and they should all generate breadcrumbs.

The menu_breadcrumb approach looks still pretty fine to me.
Isn't all we need just something like a weight to order the (possibly multiple) matches?
Or how about a variable containing the menus to consider? (I've hacked the module to exclude admin_menu to avoid mismatches...)

Before catch pointed me this issue out i was right testing and testing and was generally confused about that all.. finally my intention was pretty similar. Request > Router > Item > Menu > Breadcrumb

Can you explain me what's so wrong with it, pwolanin?

Bump.

I've pulled hair out over the last couple of weeks over the way breadcrumbs are working. For my projects with get-er-done timelines I've resorted to making fake breadcrumb systems, because the alternatives were doing some weird stuff that didn't sit well with me. For example, one menu breadcrumb modules worked great, except: menu_get_object() returned its parent's node object.

This may have nothing to do with that module... maybe it was a combination of menu_block, menu_breadcrumb, taxonomy_menu in particularly bad configuration... I feel like a cat aimlessly pawing at a wooden cage -- knowing that if I paw long enough, eventually i may stumble on a solution that makes sense. Nay, it feels fubar.

My gut tells me that weighing menus, and using those weights to determine what shows up in the breadcrumb trail is dangerously full of practica and prudent good sense. The solution feels weird, but the problem is weird. At least this makes menus work like blocks, menu_items, taxonomies, cck fields, etc... Its much easier to think in terms of numeric weights, instead of having to consider everything that happens between "where is drupal, who wants to talk to drupal, and what is going on? to various api hooks, to calling api functions within different api hooks, to the "what does it look like layer"? We get this right, I think we finally get a menu context system right.

Maybe I'm missing something in the api, but honestly -- views reference, the book module, and fake menus all seem to be required to get these projects out the door.

I'd never argue that this situation is a regression from drupal 5. breadcrumbs have always just been the canary in the gloom mines.

<---Ain't gonna complain about a new menu system that solved the whole "data, menu_callback, overriding, file organization, permissions strangeness, weird convention" thing that we used to have.

The data and logic seems to be there to make this problem not that *big* of a deal.

subscribe to help testing!

I'd love to help test this. Would you like us to try the pasted module, or the menu_breadcrumb module? I think having a breadcrumb generated for all menus is the key feature this ticket is getting at -- and I'd love to see that.

A request, please. My D7 system is not far enough along to check the multi_bc possibility. Here's a simple test: go to "/user/xxx/edit" where xxx is any uid other than your own. Does "My account" appear in the breadcrumbs? That is incorrect.

I can tell you that this did not fix the 6.x problem.

#273137: Split Navigation to User and Administration menu is a rather important usability thing we'd want to improve on. It is postponed on this issue though. I would *love* to see some progress here. Is #25 still the best summary of the issue for example?

Gentle bump from a non-programmer :-)

Me too.. The usability tests for d7 are coming up and it seems a bi silly to put so much effort into the testing when we havenb fixed the problems the previous usability testing found.

I would really lime to help. Should I install d7 and a patch or contrib module from one of these posts? Just let me know what I can do.

Thanks.

So.. Is the only thing missing the TODO weights ui in #18?

There is another TODO core about a local task that I'm not sure about.

With working code to find the right ( or at least a ) bread crumb, then the user and admin menus can be split out of the navigation menu, right? And #273137 can be .. un-postponed?

How can the contrib module from #18 be translated into a patch on core?

-YesCT ( kind of writing a note to myself, trying to digest the current status here )

I have not tested against HEAD in a few weeks, but at that time, IMHO, this wasn't even addressed, let alone fixed. I will say that D6 is seriously broken in this area. I had to code a large hook_menu_alter with several sub-functions just to fix the user/x pages.

subscribing

subscribing

@NancyDru - if you are doing *anything* with hook_menu_alter in order to afect breadcrumbs, then you are likely on the wrong track. The "My account" thing should be fixed, but is a bug that really only affects admins, so has been very low priority.

Working on this now as part of this patch: http://drupal.org/node/273137

#273137: Split Navigation to User and Administration menu