See title—if the old "Search facets" module goes, this should still work. However, if I recall correctly the dependency was rather minimal, so shouldn't make too many problems.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drunken monkey’s picture

Status: Active » Needs review
FileSize
14.43 KB

The dependency was rather larger than I thought, but I think I managed the transition quite well, now using Facet API's theming functions. Also, thanks to the Facet API's ability to show facets for a different base path, which I use with this patch, normal facet blocks can just be enabled for the facet block search and will automatically point to the search page set in the „Facets block“ display's options! There is now also an option to hide the actual block output of the display, so you can just use it to execute a search for which you can then show the normal Facet API facet blocks. (Only problem with this is that you cannot put them in a different region for only this page.)

I hope I also explained that clearly enough in the Views module's README.txt – a review of that would be nice. Other than that, please test!

@ Chris:
1) Lines 199 to 261 in display_facet_block.inc are just one struggle of imitating Facet API facet rendering. Is there maybe some simpler way to do this that I have overlooked, or could this be improved in some other way? (Or, are there even bugs in there?)
2) I had the problem that Facet API would now alter the breadcrumb on the front page (where I displayed the block), to "» [all items]". Had to put some small hack in getSearchKeys() to keep that from happening, but it will actually probably be undesirable on normal search pages as well. Is there a way to decouple the breadcrumb from the „Current search“ block (which we do want for empty searches), or could one be added?

atlea’s picture

Hi

Some feedback. I got this to work, but.. :) As my facets required a different sort than item count I tried using the "hide block" trick and got it to show the searchapi-facet. But when I click on it, it does not respect the "search page path", but rather applies the facet query string to the current path.

After some research it does not look like the FacetapiAdapter has a getSearchPath method...?

A.

drunken monkey’s picture

Yeah, sorry, forgot to mention that: the patch needs the Facet API patch in #1252644-2: Remove assumption that the facets will link back to the page they are on to work.

atlea’s picture

ok, got it! It also breaks on a term facet when i click on more than one term (flat hierarcy)...

drunken monkey’s picture

Please define „breaks“. And in what context – only in the context of this patch, or in general?

It sounds like an old bug in the database backend (#1145306: Database search returns no results when applying multiple filters on a multi-valued field), but this is already fixed and you most likely use the latest version when you are testing this …

atlea’s picture

"breaks" = no results. I am indeed testing this using the database backend, using the sept. 7 dev-version.
I have not experienced this using solr backend, but have not tried solr with facetapi.

drunken monkey’s picture

Could you test the database backend with the old facets? If this doesn't work either (and you are absolutely sure you are using the very latest version of the Search API), please re-open #1145306: Database search returns no results when applying multiple filters on a multi-valued field with more information.
Otherwise, provide more information here.

cpliakas’s picture

Project: » Search API
Version: » 7.x-1.x-dev
Component: Code » Facets
Issue tags: +Facet API integration

Moving to Search API.

drunken monkey’s picture

Status: Needs review » Fixed

Oh, sorry, forgot to mark this fixed. This was of course committed with the rest of #1182614: Integrate with Facet API.

@ atlea: If you still have problems, please try to find out more about what is causing them and then create a new issue.

cpliakas’s picture

Thanks, Thomas. I was cleaning out the queue without doing much research.

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