Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This issue will be to discuss the problems and possible strategies around taxonomy handling.
Currently:
- hierarchy is broken
- schema was changed to have per-[drupal-]field indexing of taxonomy, instead of per-vocabulary. This means we have "Filter by [field name]" blocks instead of the previous "Filter by [vocabulary name]" ones (which would also mean upgrade path in this sense is broken)
- taxonomy "hijack" (taxonomy/term/XX pages replaced using apachesolr) has been moved into its own submodule, and might not be needed if/when views integration is a reality.
Comments
Comment #1
pwolanin CreditAttribution: pwolanin commentedSince taxonomy now acts via the Field API, I don't see that going back to vocabulary-based operation is a very viable option.
If you look at the code, the taxonomy handling (E.g. indexing) is now wrapped in with the Field API handling generally.
Also, having it per field does provide some interesting benefits. For example, you can re-use terms to have different meanings. E.g. a color vocabulary, terms: white, green, brown, blue, yellow, pink
2 fields on a node choose terms from this one vocab:
#1: color of your bedroom
#2: color of your kitchen
I can now filter for a blue kitchen and white bedroom.
Note that we are also still putting all tids into the tids field, so it's possible (not default) to filter for all nodes referencing from any field the term 'red'.
Comment #2
janusman CreditAttribution: janusman commentedSome questions:
Would a site builder ever want a "filter by", say all uses of "white" from the color vocabulary, regardless of what field they were used in?
I still don't get what the problems would be to build a hierarchic tree of terms (say, for a particular field like "field_bathroom_color" where the colors would be Red, Red > Light Red, Red > Dark Red, etc)... ¿could you elaborate on that?
Comment #3
pwolanin CreditAttribution: pwolanin commented@janusman - since a single field can, at least according to the API, contain terms from multiple vocabularies, there can be no single defined hierarchy among those terms. Right?
It might be possible to make it work by essentially displaying the terms from each vocabulary as a separate hierarchy within the output, but not sure how hard that would be to code.
Comment #4
janusman CreditAttribution: janusman commentedI would say that if a node has a term relation (say, "dark red"), and a single tid is only assigned to a single vocabulary, then that vocabulary defines the hierarchy.
Right, that's what I thought we could do =) Wasn't really concerned with it being *hard*, rather I wanted to know if there was something blocking that strategy. So unless you say so I'm thinking of working on bringing in hierarchy support this way.
Now, you didn't answer my other question:
I ask because I'd like to know if we should put back in the ability to filter by term from a *vocabulary* additionally to the existing filters by termreference field. Thoughts?
Comment #5
pwolanin CreditAttribution: pwolanin commentedI think the use case for custom or other contrib modules is supported by storing the tid field. I don't think we need to actually add those facets to the 7.x module.
Comment #6
janusman CreditAttribution: janusman commentedI agree =)
Comment #7
Steven Jones CreditAttribution: Steven Jones commentedSubscribe, we need hierarchies for a project we're working on.
Maybe, as a possible stop-gap if the field contains just a single vocab, then we offer to use a hierarchy, otherwise we don't? I agree that it might be confusing to have multiple lists of hierarchies in the facet block, but essentially it just boils down to some clever for-each looping.
Comment #8
pwolanin CreditAttribution: pwolanin commentedWe might see if we can leave some of the generic hierarchy code in the main module so it can be re-used, but as above I think any actual facet block implemenetations should be in a different or custom module.
Comment #9
james.williams CreditAttribution: james.williams commentedHere is the patch that comes from my work with Steven (comment #7) on implementing hierarchical taxonomy facets. The patch:
The patch is against HEAD, and requires the (D7 version of the) patch in http://drupal.org/node/791916#comment-4095210 which adds the 'always how child facets' facet block config option before it can be applied against the stable 7.x-1.0-beta3 branch, if anyone was wondering.
Comment #10
james.williams CreditAttribution: james.williams commentedI have made a couple of modifications to the above patch, for non-hierarchical taxonomies, which should still be able to be sorted by weight (but weren't).
Comment #11
james.williams CreditAttribution: james.williams commentedSee attached updated patch after a change was made in the master branch to apachesolr.index.inc. I also enclose a version of the patch without the new prefixes that Git adds, so it can be easily used with patch -p0 (which drush make is hard-coded to use) if required.
Comment #12
james.williams CreditAttribution: james.williams commentedAttached patches fixes PHP warnings produced by patches in above comment when no facets are available.
Comment #13
janusman CreditAttribution: janusman commentedAssigning to self. Code is needing a little tweaking but seems to almost work perfectly... even OR taxonomy facets working =) Will post an updated patch soon.
Comment #14
janusman CreditAttribution: janusman commentedHere's a new patch out of a fresh pull. Everything seems to be working with taxonomy:
- AND/OR facets
- hierarchy
- breadcrumbs (which were broken on the patch from #12)
- links in current search block (although they are currently "flattened"; on the D6 branch they show as hierarchic too).
So perhaps the only thing (IMO) is the hierarchic display inside the current search block, but this is probably enough for a beta release.
Comment #15
janusman CreditAttribution: janusman commentedPatch forgotten! Posted!
Comment #16
pwolanin CreditAttribution: pwolanin commentedcommitted #15 with some code comment cleanup.
We really need some tests that make sure this works long term.
Comment #17
janusman CreditAttribution: janusman commentedRelated issue: #552152: OR facet counts are confusing