In an Open Source Content Management System like Drupal, the wide range of contributed modules often leads to multiple solutions and approaches being available to build a feature for a site. With this flexibility, rarely is there a single "best" solution to a given problem. In this series, the Mediacurrent team will cover some of the common features that our clients often request, and what tools we like to select for the job.
For our second edition of this series, we'll discuss breadcrumbs. This seemingly innocent little trail of text links intended to demonstrate "you are here" for any particular page of a site. Clients often want to put their unique stamp on precisely how breadcrumbs should behave, and many times this quickly heads down a dangerous custom path. How do we stay out of the woods with breadcrumbs? Mediacurrent debates:
1. Describe some of the challenges you've run across when working with breadcrumbs in Drupal.
Andrew Riley: I tend to use SmartBreadcrumb as my starting point for breadcrumbs, it has quite a few different options to cover things like nodes, menus and views. (link: http://drupal.org/project/smart_breadcrumb)
As far as challenges go, Drupal is flat as far as nodes go. Any type of hierarchy has to be added on (menus, urls, etc). This provides interesting problems since you pretty much have to do a lot of different types of lookups to find out the title of things. A title of a view is stored much differently than that of a node and menus are stored differently than the first two.
Robyn Green: I'm not sure it's entirely a Drupal problem, unless the argument is flexibility. The crux of the issue is that every client has a different idea of how breadcrumbs should work on their site, down to the tiniest of details such as separators and if the current page should link or not. In that regard, it's more of a lack of customization options from Drupal, but the amount of variables necessary to accomodate all the requests I've seen would be a huge project.
Jay Callicott: Recently I have gone with menu_breadcrumb and breadcrumb rules as my catch-all solution. Menu breadcrumb handles items in the menu, which is particularly helpful if you have nested menus. Then I am essentially left with node type breadcrumbs. Rules gives you the most flexibility so that's what I have gone with. The node breadcrumb module wasn't enough in the past, I still had to create some custom breadcrumbs via code. I'd like to use context for my breadcrumb setting, but it too doesn't give you the tools Rules give you, like using PHP. So with breadcrumb rules I can handle all of my node type breadcrumbs.
2. Describe some of the modules/approaches you have tried that have failed, and why?
Jay Callicott: The issue for me is not failing, per se, but having breadcrumb logic spread out across multiple modules and code which is a maintenance problem. Like you download menu breadcrumb for menus, node breadcrumb for node pages and then you write custom ones in php for 1-off pages. That's why I have gone to using just menu breadcrumb and rules for everything else. With rules you can cover both node pages and 1-off pages.
3. Anybody have any alternative go-to modules that haven't been mentioned yet?
Chris Hales: My go to module for breadcrumbs has almost always been Custom Breadcrumbs. http://drupal.org/project/custom_breadcrumbs
Andrew Riley: This might be derailing the debate but I think one of the bigger issues with Drupal is we build hierarchal websites on it but the node system is flat. Ultimately we should have another system on top of the node system that that ties into everything (nodes, views, taxonomy pages, etc) that does an overlying hierarchy that breadcrumbs and urls could pull from.
Jay Callicott: Andrew is right, for SEO and usability breadcrumbs and "directory-style" paths are helpful but we are tacking that onto a flat node system.
4. Interesting. What would you call this and how would it be configured and managed? Taxonomy could be a little bit like this but it really seems to confuse people.
Andrew Riley: Site Hierarchy? It is very similar to taxonomy or the basic menu system but really it shouldn't live in either (they both have very specific jobs and have added weight that isn't needed). This would be something along the lines of you can create a tree. Then when editing/creating each node/view/whatever you would select the parent from the SH. Then all modules that tend to implement tie into nodes/views etc would pull the info from there (think SEO modules, context/panels, path auto etc).
Josh Estep: Sounds like it should be abstract, where you capture the primary key of an item (nid for nodes etc), its type (node etc) then allow a parent/child relationship. It shouldn't need to be very complex, then views breadcrumbs etc could reference it
It should also be possible to extend this generic parent/child system to apply hierarchies to new types of things, for example: organic groups
Jeff Diecks: Interesting. This also sounds like parts of the Book Outline functionality. Maybe it is this crossover/extra functionality of Taxonomy, Menu System and Book Outline that makes these three of the easiest parts of Drupal to create client confusion.
While we didn't exactly arrive at a conclusion in this debate, I think we highlighted one reason for the lack of a "best" solution regarding breadcrumbs is the variation of requirements each client will often have. What are some of your experiences with breadcrumbs? Have you found success with any other modules or approaches that we didn't mentioned? We'd love to hear any comments you may have.