I have two taxonomy menus. Each are set up identical for breadcrumbs. However, one of them likes to attach the first taxonomy term to the breadcrumb trail. I don't understand what I may be missing?

Example:

Incorrect:
http://www.pinkgorillacycles.com/Luggage

Correct:
http://www.pinkgorillacycles.com/Helmets

Thanks for the help!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

xl_cheese’s picture

I wonder if it has something to do with with the custom taxonomy menu path type settings for the Luggage menu?

The menu path type for Helmets are default while Luggage is set to custom. The base path is set to part/taxonomy/term.

Default is taxonomy/term.

That is the only differece I know of between the two menus.

MGN’s picture

Status: Active » Postponed (maintainer needs more info)

What configuration settings are you using for custom breadcrumbs?

xl_cheese’s picture

Title:
[vocab-raw]

Path:
[vocab-raw]

xl_cheese’s picture

Was that the info you are needing?

MGN’s picture

No, but thanks for including it - it helps. I was thinking about the settings you have configured at admin/settings/custom-breadcrumbs.

Is this a vocabulary type custom breadcrumb?

In your example, are Luggage and Helmets two different vocabularies, or are these terms in one (or more?) vocabulary?

Can you also show the taxonomy structure (including weights) for the relevant vocabularies and terms.

However, one of them likes to attach the first taxonomy term to the breadcrumb trail.

And, just to clarify, is the problem that a taxonomy term is being included when it shouldn't be, or is it getting the wrong term ?

MGN’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Closing since it seems this issue has gone stale. Reopen after testing with the latest code if this is still an issue. Thanks.

xl_cheese’s picture

Status: Closed (cannot reproduce) » Active

I've updated to the latest dev and I'm still getting this behavior.

Helmets and Luggage are each a vocabulary.

The issue is that when I'm looking at Luggage I get the first term in the vocabulary attached to the breadcrumb trail.

Breadcrumb trail: Pink Gorilla Cycles → Luggage → Backpacks
http://www.pinkgorillacycles.com/Luggage

Breadcrumb trail: Pink Gorilla Cycles → Helmets
http://www.pinkgorillacycles.com/Helmets

The behavior I want is to not have Backpacks in the trail.

Weights of all the terms are 0.

Thanks for the help. As you can tell it's not a super high priorty for me to fix, but I'd like to at least look into it.

MGN’s picture

Version: 6.x-2.0-beta3 » 6.x-2.x-dev
Status: Active » Postponed (maintainer needs more info)

Can you tell me what options you have enabled on the custom breadcrumbs configuration screen (at admin/settings/custom-breadcrumbs) ?

Also what custom breadcrumbs modules do you have enabled?

I haven't tested custom breadcrumbs with taxonomy menu, so I am not sure what issues to expect, but I'll look into it.

xl_cheese’s picture

The modules I have enabled are:
Custom Breadcrumbs
Custom Breadcrumbs for Paths
Custom Breadcrumbs for Taxonomy
Custom Breadcrumbs for Views

attached is a snapshot of the settings.

MGN’s picture

Thanks. A few more questions:
Did you set up two vocabulary type breadcrumbs - one for Helmets and another for Luggage ?
Are these set up as you have shown in #3 (above)? If so, the vocabulary breadcrumb just provides the vocabulary crumb that is shown in taxonomy term pages and nodes that have these terms. It doesn't seem that the pages you are talking about (Luggage and Helmets) are either one of these.

So, can you tell me what kind of pages are set up at http://www.pinkgorillacycles.com/Luggage and http://www.pinkgorillacycles.com/Helmets?

Are these views or provided by another module?

If its a view, what kind of a view is it (Does it return a list or table of nodes?).

If its not, what module is providing the page?

Have you defined custom breadcrumbs for these pages (by path, for example?)

xl_cheese’s picture

Those pages are both generated by views.

Helmets is under the default taxonomy_term view. Path is taxonomy/term/%
Luggage is setup as a custom_taxonomy_term view. Path is parts/taxonomy/term/%

For each page I've created a Taxonomy Vocabulary breadcrumb.
Title: [vocab-raw]
Path: [vocab-raw]

Thanks again for the help.

Should I create the breadcrumb differently?

MGN’s picture

Assigned: Unassigned » MGN
Status: Postponed (maintainer needs more info) » Needs review
FileSize
1.25 KB

Thanks.

I think I see the problem. In the current code, the (singular) taxonomy term page has a path of taxonomy/term/% - so parts/taxonomy/term/% isn't recognized as a taxonomy term page (even though it is). Instead, its being treated as a view with a listing of nodes, and since the "show current node title in taxonomy breadcrumb trail" is enabled - "Backpacks" is being added.

This patch changes the current code so that any path that has component 'taxonomy' followed by 'term' is considered a taxonomy term page. This seems like a reasonable requirement, and should work fine for your parts/taxonomy/term/% construction.

Can you test the patch (against custom_breadcrumbs_taxonomy.module in the latest 6.x-2.x-dev) and let me know if this solves the problem? It seems to work fine based on my limited testing.

xl_cheese’s picture

Thanks for the fix! I've tested it and it mostly works.

One issue I see is on another menu where I have an extra level of heirarchy in the taxonomy tree. It it taking the first taxonomy tree where a product exists.
http://www.pinkgorillacycles.com/exhausts/taxonomy/term/145%20146%20117%...

MGN’s picture

Status: Needs review » Postponed (maintainer needs more info)

Interesting.

Checking out your site, it seems that the breadcrumbs under all of the other menus work fine. Only the All exhausts view (with multiple tids) is misbehaving - the subitems (like All slip-on-sport work fine. Also, the breadcrumb for the All Luggage page (which looks like it has the same url structure as All exhausts (with multiple tids) is working fine...

Is there anything different about these two views (particularly the options under arguments term_node_tid_depth...) ?

Or is there something different about the taxonomy structure - you say there is an extra level of hierarchy in the taxonomy tree, but I don't see this on the site - the menu structures appear to be the same I see the differences now...

Accessories
--Luggage
----(terms in the Luggage vocabulary)

and

Parts
--Exhausts
----(terms in the Exhausts vocabulary)
----Complete System - sport
-------sub items under Complete System - sport
Can you explain how they differ?

MGN’s picture

Status: Postponed (maintainer needs more info) » Reviewed & tested by the community

Your current link for All exhausts is http://www.pinkgorillacycles.com/exhausts/taxonomy/term/145+146+117+129+...

When custom breadcrumbs taxonomy gets a url with multiple term ids, it uses only the first - in this case 145 - and discards the rest. 145 is BMW - one of the sub terms under Complete System - sport. So the breadcrumb "by design" should be:

Pink Gorilla Cycles → Exhaust → Complete System - Sport

The (child) taxonomy term (BMW) is being omitted because the option "Show current taxonomy term in breadcrumb trail on the taxonomy term page" is not enabled.

The behavior you are seeing on your site is correct.

To avoid showing any of the vocabulary's (parent) terms in the breadcrumb, you need to make sure that the first item in the url is a parent term.

If you change your menu link to http://www.pinkgorillacycles.com/exhausts/taxonomy/term/114+115+116+117 - (i.e. list only the parent terms), I think you'll get the view you want with the correct breadcrumb.

For what it is worth, I'll add a note in the readme file explaining the behavior when multiple term ids are present for a hierarchical taxonomy breadcrumb.

I am marking this RTBC since it appears that all is working as expected.

xl_cheese’s picture

Thanks for the explaination!

MGN’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 6.x-2.x-dev.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.