Distinguish from custom_breadcrumb

thaks for the feedback. not that some of the modules are in the same field have been compared http://drupal.org/node/751066 but we will write some text regarding this on the project page.

putting on my name as documentation

Menutrails is not mainly intended to be a breadcrumb module, but a module to activate a menutrail for node and taxonomy pages (to fix the not showing active state / submenu's problem). It has however the ability to synchronize the breadcrumbs with the active menu trail.

I mentioned 5 issues in the comparisation (see link in Bert's post). You can (in most cases) fix 1 and 2 with menutrails. But Hansel offers far more flexibility (but also complexity) with your breadcrumbs. Using switches it is possible to have different breadcrumbs depending on url arguments, domains or whatever you like by writing new switches for Hansel.

But there is one big difference between Hansel and all other breadcrumb modules. Other breadcrumb modules enable you to fix breadcrumbs at "some places" (like for the "nodes not in menu" issue). Hansel provides a way to configure your own breadcrumbs (for all pages) and sweep away the breadcrumbs from Drupal core (thus entirely replacing the old breadcrumbs instead of altering it).

I feel like this is way more powerful than custom breadcrumbs, I only wonder how the performance compares.

I did some query logging to analyze the performance.

How many queries Hansel uses depends on the used breadcrumb actions and switches. Some notes on this:

• Some breadcrumb actions and switches call node_load, which is in all cases the node from the current page, which is already statically cached, thus these switches / actions do not use extra queries.
• The breadcrumb action "link to user" does a user_load. When used on the user pages this is already statically cached. But when used on node pages this action requires extra queries.
• The "add term path" calls taxonomy_node_get_terms_by_vocabulary or taxonomy_node_get_terms. These functions use 1 extra query (if not statically cached - which isn't most of the times).
• When using token module the function token_replace is used. This function uses in my tests 6 or 7 extra queries. This function is not called when you don't use tokens.
• Hansel itself does (on page generation) only a cache_get (to get the whole configuration), which uses 1 query on a default Drupal installation. Can be optimized with memcache.
• The drupal l() function calls drupal_get_path_alias(), which uses 1 query to get the alias (unless the same link was used before). This is true for all links, not just links from Hansel. There is also a way to optimize this, see this post on my blog.

For a Drupal installation without memcache, and with a common Hansel configuration, this module will use only a few queries. When using tokens (which is not necessary for most usecases) this will be around 10. When not using tokens, with memcache installed and path aliases cached, Hansel will work for most pages with 0 additional queries.

Summarized; performance on Hansel is not worth worrying about :)

Small note: user_load is not statically cached, one of the horrors of that function :)

I think that the difference is clear enough now. Closing this issue.