On 1/28/07, Dries Buytaert <dries.buytaert@gmail.com> wrote:
I'd prefer to postpone this discussion until CVS HEAD is back in a working state that we're all familiar with, and that is (mostly) backward compatible with regard to breadcrumbs. Yep, I want the new breadcrumb behavior to act _exactly_ like the old/current system in Drupal 5. By default, the breadcrumb should follow the menu structure, IMO. When a page does not correspond with a menu item, there is no breadcrumb, or the breadcrumb can still be set using drupal_set_breadcrumb().
I agree with Dries on this one. My view has always been that "the menu hierarchy" is the one-and-only logical reference model for Drupal's navigation system. All of the various navigational elements on a site - e.g. side-block nav menus, breadcrumbs, pri/sec links, TOC links, prev/next/up page links - should merely be visual representations of this single logical reference model. If any of these visual elements are inconsistent with each other, that merely serves to confuse the user, and to blur the site's hierarchy. Navigational aids that aren't tied to the menu system have their place - e.g. in 'related links' blocks, in taxonomy tag links, in links to anchors on the same page, etc. But breadcrumbs do not fall into this category. The menu structure in Drupal 5.x works as follows: by default, menu parents are determined by their system path - e.g. node/123 yields 'home > node > 123'; but this is overridden if the menu item is given a different parent on the 'admin/build/menu' page by the administrator - e.g. 'home > our work > manufacturing > plastics (node 123)'. This, in turn, _can_ also be overridden by menu_set_location() (or, even worse, by drupal_set_breadcrumb()), but personally, I've always considered that to be a hack, as it generally defeats the whole purpose of letting the _user_ decide where they want their menu items to go, and what they want their breadcrumbs to look like. I too would like to see this remain as the default way of determining breadcrumbs. But a better API for overriding this behaviour would certainly be welcome as well. Cheers, Jaza.