Hi, We all know that our breadcrumb is not perfect. It's very far from it, actually. As breadcrumbs are currently removed from HEAD, we have a blank sheet to draw something pretty on it. I discussed this long with webchick, and here are some results: *) There is no one solution that fits all. *) Sometimes you even want multiple breadcrumbs. *) Core needs to provide some default and configurable breadcrumb(s) *) Contrib should be able to add more breadcrumb schemes With that said, here are some breadcrumb schemes that I believe should be core: *) Based on path. I have page/subpage/pagethird and the breadcrumb should read "link to page" >> "link to page/subpage" >> "title of page/subpage/pagethird". Or without the title. Remember, there is no one solution that fits all. *) Based on tags. Vocabulary name >> Hierarchy of tags provided it's a single hiearchy. Here, if you want you can provide multiple very easily, even ordering is not a problem, vocabularies have weights already. I hereby propose the creation of breadcrumb module based on Eaton's token module and partially on his custom breadcrumb project. I strongly believe that token module needs to find its way to core, it's not big and it's very useful. A good read is http://www.visiblearea.com/cgi-bin/twiki/view/Patterns/Homeward_path (thanks Sepeck for the link). Regards, NK
With that said, here are some breadcrumb schemes that I believe should be core:
*) Based on path. I have page/subpage/pagethird and the breadcrumb should read "link to page" >> "link to page/subpage" >> "title of page/subpage/pagethird". Or without the title. Remember, there is no one solution that fits all. *) Based on tags. Vocabulary name >> Hierarchy of tags provided it's a single hiearchy. Here, if you want you can provide multiple very easily, even ordering is not a problem, vocabularies have weights already.
A path could be either a set of similar url aliases, or a menu hierarchy. So "Based on path" can be divided, adding a third possibility: * Based on a menu hierarchy * Based on url aliases, regardless of their position in the menu (router, dispatch?) system. Zohar
Not to forget breadcrumbs based on (book) outlining. Core can obviously generate each of these default paths, the problem seems to lie mostly with a way for the webmaster, or maybe the content creator (permission?), to specify which of these defaults to choose. Maybe some AJAXy breadcrumb selector could be used on the node edit form ? - display a list of such default breadcrumbs (path, book, taxonomy, menu...) - allow simple validation of either, just like in autocomplete fields - allow drag and drop of bits and pieces ----- Original Message ----- From: "Zohar Stolar" <z.stolar@gmail.com> To: <development@drupal.org> Sent: Sunday, January 28, 2007 5:58 AM Subject: Re: [development] breadcrumbs
With that said, here are some breadcrumb schemes that I believe should be core:
*) Based on path. I have page/subpage/pagethird and the breadcrumb should read "link to page" >> "link to page/subpage" >> "title of page/subpage/pagethird". Or without the title. Remember, there is no one solution that fits all. *) Based on tags. Vocabulary name >> Hierarchy of tags provided it's a single hiearchy. Here, if you want you can provide multiple very easily, even ordering is not a problem, vocabularies have weights already.
A path could be either a set of similar url aliases, or a menu hierarchy. So "Based on path" can be divided, adding a third possibility: * Based on a menu hierarchy * Based on url aliases, regardless of their position in the menu (router, dispatch?) system.
Zohar
I'd like to outline some point: DokuWiki is using two ways breadcrumb, one is the current user's navigation history, which might only list the last 5 pages and a second breadcrumb which resembles Drupal's breadcrumb. I think I'd go for provding an additional argument(s) to hook_menu.
On 28-Jan-07, at 3:15 AM, Omar Abdel-Wahab wrote:
I'd like to outline some point: DokuWiki is using two ways breadcrumb, one is the current user's navigation history, which might only list the last 5 pages and a second breadcrumb which resembles Drupal's breadcrumb. I think I'd go for provding an additional argument(s) to hook_menu.
Ugh, I hate that. I find that so utterly confusing: sites with magical shifting breadcrumbs. I also hate when the breadcrumb trail magically switches depending on how I find a page. (Home >> Tags >> Foo sometimes, Home >> Forums >> Foo) other times. To me, the breadcrumb trail is the site author's indication of where a given page belongs in the structure of the site. This is really helpful when you end up at a random page via Google. They also help find more pages like the one I'm looking at. Tags, on the other hand, are a user's representation of where they think that page belongs. They are two totally different things. I'll use an example from Amazon.com to illustrate: http://www.amazon.com/Hissing-Fauna-Are-You-Destroyer/dp/B000KWZ94U/ sr=8-1/qid=1169998791/ref=pd_bbs_sr_1/102-1200809-9979317? ie=UTF8&s=music Now if you scroll to the bottom of the page (no idea why this is at the bottom), you'll see a breadcrumb trail of: # Styles > Alternative Rock > Indie & Lo-Fi > Indie Pop > General This is how Amazon.com thinks this album fits in relation to other content on their site. If I click "Indie Pop" I'm taken to a listing of other albums like the one I'm looking at (in fact I own about half of those on the front page ;)). This is very useful. Now let's say instead I click the tag "weird," which is how a user has categorized it. This brought up a bunch of completely unrelated crap, including a George Bush Kennebunkport art poster, which I am very unlikely to purchase. ;) Really, my only major beef with Drupal's breadcrumbs is that the current page (non-linked) is not included. See http:// developer.yahoo.com/ypatterns/pattern.php?pattern=breadcrumbs However, I guess that's why we want to make it all configurable. ;) +1 for token module in core, +1 for core providing some kind of 'breadrcumb api' that can be expanded with contrib modules with an "80% solution" implemented as the default. -Angie
+1 on a breadcrumb API. Eaton's modules are a good starting point. The default is not that important when one can override how breadcrumbs are created.
On 1/29/07, Angela Byron <drupal-devel@webchick.net> wrote:
Really, my only major beef with Drupal's breadcrumbs is that the current page (non-linked) is not included. See http:// developer.yahoo.com/ypatterns/pattern.php?pattern=breadcrumbs
However, I guess that's why we want to make it all configurable. ;)
You can easily add the current page (linked or non-linked) to the breadcrumb trail by overriding theme('breadcrumb'). Cheers, Jaza.
I've been letting this thread go by, as I agree with most of what has been said. I'd like to add my thought: let's make the breadcrumbs an array of paths. I dislike that there is just one breadcrumb, and if Module A creates a breadcrumb, and Module B later suggests a different path, A's is overwritten. I would suggest copying the node access system and having modules suggest breadcrumbs. Then provide the theme layer with this information and let it choose. By default the BC's can be ranked by module execution order, so this would be basically backwards compatible. I think a hook_breadcrumb($path, $node = NULL) { return array(this, is, my, path); } would be useful. Perhaps returning a well-formed links array (so we could have a hook_alter_breadcrumb). Then, modules, user input, or the theme layer could choose a breadcrumb based on their preferences. Welcome the Bread Crumb API (a subset of the Data API, *nods at Adrian*) -Mark On 1/28/07, Jeremy Epstein <jazepstein@gmail.com> wrote:
On 1/29/07, Angela Byron <drupal-devel@webchick.net> wrote:
Really, my only major beef with Drupal's breadcrumbs is that the current page (non-linked) is not included. See http:// developer.yahoo.com/ypatterns/pattern.php?pattern=breadcrumbs
However, I guess that's why we want to make it all configurable. ;)
You can easily add the current page (linked or non-linked) to the breadcrumb trail by overriding theme('breadcrumb').
Cheers, Jaza.
Op zondag 28 januari 2007 08:18, schreef FGM:
Not to forget breadcrumbs based on (book) outlining.
Lets just conclude that we should *not* focus on all the possible breadcrumb-schemes possible, there are too many :) A breadcrumb is an array of 'objects': one » two » three, or one » twenty » hundred » three. the 'path' between 'one' and 'three' can go via 'two', but also via 'twenty' and 'hundred'. It all depends on your site, the modules and your specific wishes. We should find a way to a) define these arrays of objects in such a way that the owner of a site has them all at his/her disposal. and b) to allow flexibility for modules to define where they appear in a breadcrumb, and how they appear there. Example: forum (being taxo term) wants "home » discussion » forums » Cheese" While a frontpage-entry (a forum item promoted) may want "home » tags » Cheese". Drupal core should at least allow the flexibility to choose both. My idea: modules expose breadcrumbs if they like. The last (basis) module providing breadcrumbs is the menu-module (system.module in fact), as a fallback when no module exposed items is the menu trail. Every module adds certain namespaces (yet to be defined, but think about: title, parent_id, url/path) and a weight. In the end, Drupal core should render the item with the lowest #weight for a certain item. That way, your module can assign lower weights then that-other-module if you insist on overriding. But it is also simple enough to develop a breadcrum-management-module. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
On 28 Jan 2007, at 10:41, Karoly Negyesi wrote:
The last (basis) module providing breadcrumbs is the menu-module (system.module in fact)
No way. The menu system has nothing to do with breadcrumbs. Or very little.
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(). -- Dries Buytaert :: http://www.buytaert.net/
By default, the breadcrumb should follow the menu structure, IMO.
As you decree, so it will be done. Just tell me what is "the menu structure". Is it the router structure? Ie. if I have node/123, then the next up is node. Is it the menu structure? The links you click to reach the page? This is doable. While I try to mirror D5 menu with D6, I wanted to differ here. If not now, we can do later. I am fine.
Karoly Negyesi wrote:
By default, the breadcrumb should follow the menu structure, IMO.
Just tell me what is "the menu structure". Is it the router structure? Ie. if I have node/123, then the next up is node. Is it the menu structure? The links you click to reach the page? This is doable.
At least for me, the "menu structure", as far as breadcrumbs are concerned, is not the way Drupal defines a menu (e.g. a 2 miles long array of paths and callbacks), but the way the user perceives it - a simple, visible hierarchy, that is defined by the administrator, through the admin/build/menu interface. So node/123 could show, by default, its menu parent, if there is one defined, or "main", or "home", in case there is no parent (in case node/123 is not included in a user-defined menu).
[Karoly Negyesi] *) Based on tags. Vocabulary name >> Hierarchy of tags provided it's a single hiearchy. Here, if you want you can provide multiple very easily, even ordering is not a problem, vocabularies have weights already. I believe having a taxonomy based breadcrumb trail is extremely useful (which is why I created the module taxonomy_breadcrumb http://drupal.org/project/taxonomy_breadcrumb ). I would fully support having this type of functionality as an option in core. Craig -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Zohar Stolar Sent: Sunday, January 28, 2007 1:56 PM To: development@drupal.org Subject: Re: [development] breadcrumbs Karoly Negyesi wrote:
By default, the breadcrumb should follow the menu structure, IMO.
Just tell me what is "the menu structure". Is it the router structure? Ie. if I have node/123, then the next up is node. Is it the menu structure? The links you click to reach the page? This is doable.
At least for me, the "menu structure", as far as breadcrumbs are concerned, is not the way Drupal defines a menu (e.g. a 2 miles long array of paths and callbacks), but the way the user perceives it - a simple, visible hierarchy, that is defined by the administrator, through the admin/build/menu interface. So node/123 could show, by default, its menu parent, if there is one defined, or "main", or "home", in case there is no parent (in case node/123 is not included in a user-defined menu).
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.
On Sunday 28 January 2007 4:59 pm, Jeremy Epstein wrote:
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.
Agreed. The only place where I've found that doesn't make sense is when there's an index page involved. Eg, I don't want to put all "product" nodes into the menu directly, but want a breadcrumb and menu parent of the product index page (which is a view or panels or whatever). That I can usually hack around with menu_set_location() and friends. An API would be nicer, if it was flexible enough. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
* Based on a menu hierarchy
It seems everyone is married to the menu idea. What you guys seems to forget that an overwhelming number of pages do not appear in your menu. taxonomy/term/1 , taxonomy/term/1+2 , node/648543675643854 and so on. I think it's a waste trying to figure out a way the menu system could provide a breadcrumb. Of course, in the rare case when it is a menu item, the chain of menu items to be clicked could be a breadcrumb. That's another scheme indeed but I do not think it could be the base to fall back to -- too rare.
Op zondag 28 januari 2007 10:47, schreef Karoly Negyesi:
That's another scheme indeed but I do not think it could be the base to fall back to -- too rare.
So, you are saying we should not have a default fallback? Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
participants (12)
-
_craig -
Angela Byron -
Bèr Kessels -
Dries Buytaert -
FGM -
Jeremy Epstein -
Karoly Negyesi -
Khalid B -
Larry Garfield -
Mark Fredrickson -
Omar Abdel-Wahab -
Zohar Stolar