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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pwolanin’s picture

Since 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'.

janusman’s picture

Some 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?

pwolanin’s picture

@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.

janusman’s picture

I 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.

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.

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:

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 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?

pwolanin’s picture

I 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.

janusman’s picture

I agree =)

Steven Jones’s picture

Assigned: Unassigned » Steven Jones

Subscribe, 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.

pwolanin’s picture

We 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.

james.williams’s picture

Assigned: Steven Jones » Unassigned
Status: Active » Needs review
FileSize
19.72 KB

Here is the patch that comes from my work with Steven (comment #7) on implementing hierarchical taxonomy facets. The patch:

  1. Enables hierarchies for taxonomy facets that use a single vocabulary that uses a single hierarchy
  2. Fixes taxonomy term reference fields to index parent terms (this was only being done for per-vocab facets)
  3. Adds an option to sort by weight (which is only available for facets that are hierarchical in this way)
  4. Adds an option to en/disable sorting active facets first (since this can come out a bit strange when mixed with sorting by weight & showing hierarchy)
  5. Extends the 'always show child facets' option for hierarchical facets to use the following options: Always show children with hierarchy / Only show children in hierarchy when parent is selected / Never show as hierarchy (i.e. show all facets as a flat list).
  6. When 'OR'-ing, leaving parent or child facets ticked makes little sense, since child terms are automatically included in a search for a parent term, so usability is improved since less clicks are needed now.

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.

james.williams’s picture

I 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).

james.williams’s picture

See 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.

james.williams’s picture

Attached patches fixes PHP warnings produced by patches in above comment when no facets are available.

janusman’s picture

Assigned: Unassigned » janusman

Assigning 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.

janusman’s picture

Here'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.

janusman’s picture

Patch forgotten! Posted!

pwolanin’s picture

Title: Discuss strategies for taxonomy handling in 7.x branch » Fix taxonomy hierarchy handling in 7.x branch
Status: Needs review » Fixed

committed #15 with some code comment cleanup.

We really need some tests that make sure this works long term.

janusman’s picture

Status: Fixed » Closed (fixed)

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