Custom Breadcrumbs 2.x

I've started working on a few ideas for this and could use some feedback. As Eaton pointed out, each page type essentially requires its own breadcrumb module, implementing whatever approach is necessary to insert a breadcrumb on that page type. I think custom breadcrumbs could serve as the base module that helps to organize and coordinate other breadcrumb modules, which would be packaged with custom_breadcrumbs as dependent submodules. Custom breadcrumbs should provide whatever hooks are needed to organize and coordinate the submodules into a coherent whole.

With coordinated development in one package, it will be easier to make sure all submodules work together and all page types can be handled. To the degree that interface code can be shared, they will be smaller than independent modules and easier to adminster since they are grouped together. Finally, administrators can choose what submodules to install for a particular site.

I've made the following changes to the base custom_breadcrumb module, and have written a views submodule. I am working on a submodule to provide breadcrumbs at specific paths, and then moving on to implementing taxonomy_breadcrumb in this framework. I know there is a lot of interest in breadcrumbs for panels, but I don't use panels. So someone else needs to step up and figure out how to do that. I'll be happy to help, but I can't test it right now.

Proposed modifications to custom_breadcrumbs 6.x-2.x:

• For the user interface, with only the base custom breadcrumbs module installed, it would look very similar to 6.x-1.4, but with two tabs: LIST, and NODE TYPES.
• LIST is a MENU_LOCAL_DEFAULT_TASK at admin/build/custom_breadcrumbs/list that calls custom_breadcrumb_page() to list all defined custom breadcrumbs in a table that displays the breadcrumb name, the page type, and a link to edit the breadcrumb. For the base cb module, the page type is 'node'. Breadcrumbs for views pages would have page type 'views', etc.
• To list their breadcrumbs here, submodules would implement a new hook_cb_load_all_breadcrumbs() that returns an array of breadcrumb objects with properties 'name' and 'breadcrumb_type' and 'bid' so it can be listed on the page and linked to the submodule edit page (at admin/build/custom_breadcrumbs/type/bid, i.e. admin/build/custom_breadcrumbs/node/1 or admin/build/custom/breadcrumbs/views/4 ..)
• NODE TYPES is a MENU_LOCAL_TASK at admin/build/custom_breadcrumbs/node/add that provides a form to add node-type breadcrumbs. I am starting with the current cb edit form, but this can be modified later.
• Submodules would implement hook_menu to add their own tabs (MENU_LOCAL_TASK) at admin/build/custom_breadcrumbs/type/add (where type is node, views, taxonomy, path, panel, ... ) and a provide an edit form callback at ../type/edit.
• Submodules would be responsible for providing and managing their own database tables.
• Custom breadcrumbs edit form elements that could be useful for other modules would be available via a custom_breadcrumbs_common_form_elements() function. Submodules could provide their own edit form (or use the base custom_breadcrumbs form and use hook_form_alter to add their specific fields.
• I can see one custom_breadcrumb function that other submodules could use to set the breadcrumb: function custom_breadcrumbs_set_breadcrumb($breadcrumb, $node = NULL), but the submodule would need to decide when its appropriate to call this function, and provide a compatible breadcrumb object.

What am I missing? Any alternative approaches? Any input (aside from 'subscribe') would be appreciated.

Another idea for the custom_breadcrumbs api. Provide a hook that allows a module to register pages for custom_breadcrumbs, then serve the custom breadcrumbs by calling custom_breadcrumbs_get_breadcrumb($module_name, $page_name). I think the same can be accomplished through theming, but this has the advantage of gathering together all custom breadcrumbs in a consistent interface with breadcrumb trails stored in tables, rather than within individual files.

One more idea: Provide a custom breadcrumb block, so I can display it wherever I want.

Currently this seems to be taken care of (or not) by themes, which I am not very happy with. :)

Other ideas:

• multilingual support built into custom breadcrumbs 2.0 using the patch in #173173: Multilingual support
• Use a common table structure and the same custom_breadcrumbs_load_breadcrumbs() function to load breadcrumbs for all submodules for consistency. Each submodule table will need (at least one) unique field to characterize the breadcrumb. For nodes, this would be the node type. For views page and specific paths, it would contain the path, for taxonomy terms it would be the term id..., for module pages (supported by custom_breadcrumbsapi) it could be the page name....and so on.

  To support this, each submodule implements a hook_cb_breadcrumb_info that provides the table, special field, and breadcrumb type (for display), such as:

  function custom_breadcrumbs_cb_breadcrumb_info() {
    return array('table' => 'custom_breadcrumb', 'field' => 'node_type', 'type' => 'node');
  }
  

  Custom breadcrumbs can then use this to manage the breadcrumb (load, save, delete...), preventing code duplication in all the submodules and providing a base uniformity of the breadcrumb object.

  To load breadcrumbs, custom_breadcrumbs can use a function definition like:
  function custom_breadcrumbs_load_breadcrumbs($module, $param = array() ) { ...

  Where $module is the name of the module implementing hook_cb_breadcrumb_info, and $param is an array of the form 'field' => $value, used to specify the breadcrumbs to load.
  For example:
  $breadcrumb = custom_breadcrumbs_load_breadcrumbs('custom_breadcrumbs', array('node_type' => $node->type));
  would be used to load a node-type breadcrumb, while
  $breadcrumb = custom_breadcrumbs_load_breadcrumbs('custom_breadcrumbs_views', array('bid' => $bid));
  would be used to load a views breadcrumb with breadcrumb id $bid. Called without the $param argument, the function would return all breadcrumbs from the submodule's table.

As a starting point to test these ideas and encourage discussion, I've started a 6.x.2.x-dev release. If you choose to test, be careful - its definitely not production yet...but feedback from the adventurous is appreciated.

Hey Everyone,

I just downloaded and tried custom breadcrumbs for the first time about a week ago and am not all that familiar with it just yet. I'm also not really a programmer and don't know the inner workings of drupal and module development. So, I apologize for my ignorance. =)

The module (v 6.x-1.4) has been working great except for overriding the active menu trail and working with views.

I just tried downloading the latest 6.x-2.x-dev (March 29, 2009 - 05:06) and noticed something that I couldn't do in the 6.x-1.4 version I was using. In 6.x-1.4 I could add multiple custom breadcrumb trails for a given node type. In the 2.x dev version it seems like I can only have one custom breadcrumb per node.

I'm building a site for a college and have node type = "News". I would like to be able to have a different breadcrumb trail for News items that are in the "Alumni" section of the site than in the "Faculty" section of my site.

So, I had some PHP in my custom breadcrumb trail that would test for a string in the URL that got appended in my View. This way I can test for "Alumni" in my URL and show a breadcrumb trail like Home > Alumni > News. And then I can have a second custom breadcrumb that will test for "Faculty" and the breadcrumb would be Home > Faculty > News.

With 2.x dev it seems like I can only have one custom breadcrumb trail per node type. Did I overlook something?

Thanks!
-Tim

You are absolutely right...looks like I butchered that valuable feature. It will be corrected shortly...

Thanks for testing

Panels integration would be nice too.

I love this module!

But I miss one thing:
The ability to use tokens and wildcards when specifying a path where the breadcrumb is to be set, e.g. if one wants to set a breadcrumb for the path user/[uid]/bookmarks or user/*/bookmarks.

Keep up the good work! It sure is appreciated! :)

Closing now that cb 2.0 has an official beta release. New feature requests should have their own issues now.