This issue is related to http://drupal.org/node/103422

There is no point in displaying a refine block when there is only one item to refine. The supplied patch fixes this.

CommentFileSizeAuthor
refine_by_taxo-more1term.patch746 bytesmo6

Comments

Bèr Kessels’s picture

I am not entirely sure about this. AFAIK there are quite a few cases where one would still want to be able to say 'also in'. Consider all the possible 'refinements' methods, please.

mo6’s picture

Well, yes, the check only applies if you are only using the AND relation which IMO is the most commonly used when 'refining' (narrowing down your selection).

Bèr Kessels’s picture

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

I am not happy with this change. Maybe I am understanding some logic wrong, but I certainly see no need to ignore the block with only one item. That item still is a useful filter, not?

I would agree that the filter blocks make no sense when there is only one *node* to 'list', but that is not what this patch does, afaiks.

mo6’s picture

The patch is not complete. But let me try to explain the situation which led me to suggest it. Say you have two categories:

- category "cat1" with term "taxonomy/term/11", "taxonomy/term/12"
- category "cat2" with term "taxonomy/term/21"

and the nodes:

- node "A" associated with "term/11" and "term/21"
- node "B" associated with "term/11" and "term/21"
- node "C" associated with "term/12" and "term/21"

and two refinement blocks "refine with AND interconnected through nodes".

When you select "taxonomy/term/11" you'll see two nodes "A" and "B" and a refinement block pointing to "taxonomy/term/11,21". This selection shows the same nodes "A" and "B" and is useless. Selecting "taxonomy/term/21" will show three nodes and two choices pointing to "taxonomy/term/21,11" and "taxonomy/term/21,12" which is useful.

Bèr Kessels’s picture

Yes, I think it makes sense. But then we must calculate the remaining nodes, and not the remaining terms.