Summary
The attached patch adds a setting to arguments that allows arguments to be excluded from being populated by facet blocks. This patch also cleans up the URL generation code in apachesolr_views_query.inc and thereby properly fixes #856522: Taxonomy facet blocks no longer working without having to special case taxonomy arguments.

Details
Currently, an argument always gets populated if a facet for the same field as an argument is available. For example, this makes it impossible to use taxonomy facets if also relying on a taxonomy tid passed from the URL (as on taxonomy/term/%tid). Currently, when on taxonomy/term/1, a taxonomy facet (no matter whether in the same vocab or not) has a link like taxonomy/term/1,66.

With this patch, instead, you can just add two taxonomy term arguments. You then set the first to not be populated by facet blocks, while leaving the second at the default (i.e., allow to be populated by facet blocks). You then get nice links like taxonomy/term/1/66. You can set the second argument to accept a list of tids and simply add as many taxonomy facet blocks to your nice apachesolr powered taxonomy listing without breaking the basic View URL.

This patch also switches to consistently using the array keys of $this->_facets instead of apachesolr_get_enabled_facets(), which works for taxonomy terms without having to special case anything.

We're using this patch successfully to power all taxonomy term listings with apachesolr_views and taxonomy term facets (for different vocabs) without "losing" the term actually being viewed.

This patch is sponsored by Xarxa Media GmbH.

Comments

Frando’s picture

StatusFileSize
new6.25 KB

The patch.

digi24’s picture

Thank you very much for the patch. It does not work for me yet, but I assume it is a local problem of my installation. It is working as described in the first post. It just does not seem to play nice with panels and pathauto for me, but I like the general idea of this patch.

alibama’s picture

has anyone tested this in the latest dev? I know that the bug is still there...

alibama’s picture

StatusFileSize
new147.05 KB

I'm not seeing this as a working patch - attached is a screenshot. At the top is a checklist of the exposed filter for content types, at the left is a block of facets that include all of the content types that were allegedly excluded in the view... or perhaps I misunderstand the objective of this patch

alibama’s picture

This patch seems to help http://drupal.org/node/543386 but if I exclude a content type from the search as an exposed filter and try to limit the content to the selected nodes it doesn't respect it in the search returns - ie if i say just give me stories and book types and not pages i still returns the pages in the result