Fix taxonomy hierarchy handling in 7.x branch

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

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.

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.

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.

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.

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

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.

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

committed #15 with some code comment cleanup.

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