In which GUI and breadcrumbs don't get along

Ah, breadcrumbs, how I hate you. Such a tiny little piece of a site, yet so much complexity and time spent. For some clients, you would think this is their number one must have feature based on how much time they spend checking and critiquing them page-by-page.

Existing solutions

In typical Drupal fashion, "there's a module for that!" Or more truthfully, "there are 17 modules for that!" Let's run down a few.

Please note that I am NOT hating on these modules because they're bad. Most of them are actually quite good for the tough problem they're trying to solve.

Custom Breadcrumbs

Custom Breadcrumbs is perhaps one of the earliest modules for this, dating all the way back to 2006. It has a bunch of submodules and a fancy interface that looks like this:

And that's just nodes. There are also interfaces for Views, Panels, Taxonomy, and Paths. Now, I'm not saying this interface is bad--it's not. But I bet you couldn't understand it at first glance. That's because breadcrumbs are just a hard thing to configure visually. (I'm going to say that again so be ready).

How much code does Custom Breadcrumbs ship with?

That's 6258 lines, counting a few text files and comments and blank lines. For Breadcrumbs. Debugging when things don't work as they should is obviously no picnic.

Crumbs

Crumbs is less than 4 years old so it's just a toddler compared to Custom Breadcrumbs. Let's take a look at a few of its admin pages.

Here's how you specify a breadcrumb pattern for content:

And here's a snippet of how you choose which plugins take priority over other plugins:

Again, these aren't bad interfaces by any means. They're just symptoms of the problem, which is that breadcrumbs are just a hard thing to configure visually.

How about code?

Crumbs currently ships with 9135 lines of code, again including text files and comments and blank lines.

Hansel

Hansel is about as old as Crumbs and touts the slogan "Breadcrumbs done right!" It contains 7 modules (one each for Domain, OG, Taxonomy, Forum, Exporting, the UI, and core functionality) and weighs in at a lightweight 4421 lines currently.

Here's what it looks like:

Would you know what to enter where on that screen? Would you know how to build out breadcrumbs for nodes tagged with a taxonomy using that? Yet again, this isn't a problem with the module, the module is fine. Breadcrumbs are just a hard thing to configure visually.

Others

This list is by no means complete. Here are a few others that exist and are, in my perhaps grumpy opinion, either lacking in functionality or equally as bulky and confusing.

• Path Breadcrumbs (here's a screenshot)
• Breadcrumbs By Path (only works for items that follow a predictable nested URL aliasing convention)
• Menu Breadcrumb (only works for items in menus)
• Others? If you know of another breadcrumb module that you absolutely love, feel free to tell me all about it in the comments.

Why are we here?

Easy! Breadcrumbs are just a hard thing to configure visually!

They can depend on so many things and they need to satisfy so many different use cases, that it's just really hard to support all of that and do it in a way that isn't a GUI onslaught.

Let's take a specific example. Say we have just one single content type (just one!) called "Story". And let's pretend that there's a "Category" taxonomy attached to it. Here are some very common and completely valid ways one might want to set up those breadcrumbs:

1. Make all news authored by a specific user named John Writer follow the "Editorials > John Doe > Title Of Post" pattern.
2. Make all news under the "Press Release" taxonomy term (in the Categories vocabulary) follow the "Press Releases > Title Of Post" pattern
3. Make all news posted before the current calendar year follow the "News Archive > Year > Month > Title Of Post" pattern
4. Make all news posted in the "Blog" taxonomy term follow the "Blog > Author's Name > Year > Month > Title Of Post" pattern

So that's four completely different use cases all on the same content type with only one taxonomy attached to it. That doesn't even touch on multiple content types, multiple taxonomies, different entities (user profiles, and Drupal Commerce products are quite common) or even non-entity pages (Views pages, Panels pages, etc.).

Do you see what I mean? It's a losing game.

Blame "Invented Here" syndrome or Drupal's love of all things GUI, or both. Either way, most people are trying to make the best of a bad thing by working around the various failings of these contrib modules.

An alternative approach

You are a programmer. Do it in code. It's easy! Just use our friend <a href="https://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_set_breadcrumb/7">drupal_set_breadcrumb()</a> like so:

Here's a rundown of how you could satisfy the 4 use cases above in code, in a few minutes.

1. Use hook_node_view($node), grab the author out of $node->uid, and if it's John Writer, set that custom beadcrumb using drupal_set_breadcrumb().
2. Use hook_node_view($node), grab the category out of $node->field_news_categories (or whatever the field is called), and run taxonomy_term_load() to grab the whole term, and if the $term->name is "Press Release", then set that breadcrumb.
3. Use hook_node_view($node), and if date('Y', $node->created) < date('Y') then set the breadcrumb by passing date('Y', $node->created) and date('F', $node->created) into drupal_set_breadcrumb() for the year and month.
4. Same basic idea as #2 above.

Or maybe you're adding breadcrumbs for a Views page? Throw it in a Views hook like hook_views_pre_render(&$view). Oh, you're trying to add breadcrumbs to a taxonomy term page? Throw a drupal_set_breadcrumb() into hook_taxonomy_term_view($term) and call it a day.

See what I mean? This is basic stuff for any Drupal developer, and it saves you many thousands of lines of code and potentially a lot of time debugging that code and trying to understand the interfaces.

Caveats

This method won't work when you're dealing with either of the following scenarios:

1. You need to accommodate new breadcrumb patterns as things are changed without being able to make code changes. For example, a new promotion is being run tomorrow, with no notice, and that's not enough time to push a code change through QA and find a decent launch window by then. Or maybe you're just an editor who doesn't have code access at all.
2. You need to accommodate clients who want to add and configure their own breadcrumbs without relying on you to code it. There's still the difficulty in getting them a module with a UX they can wrap their non-technical brains around, but it's more doable than teaching them to code.

However, if you're not in one of those two situations, then I highly recommend you rid yourself of whatever breadcrumb GUI you've been using.

Or convince the client to get rid of breadcrumbs altogether!

Read this next: Drupal and “Invented Here”