Some sites might want those facets but use another module (such as apachesolr_views) to build and run the query. Handling facet blocks in a separate module would allow those sites to disable apachesolr_search if they want to.

apachesolr_search would depend on that new module.

This could also be a step towards #405206: Allow Apache Solr to be the default, let search module index 0 nodes per cron run.

CommentFileSizeAuthor
#1 pull-facet-blocks-out.patch26.29 KBDavid Lesieur
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

David Lesieur’s picture

Status: Active » Needs review
FileSize
26.29 KB

Basically, this is just moving code around and renaming some functions. No changes made to the logic.
One function was moved to apachesolr.module instead of the new apachesolr_facets.module because apachesolr_search.module also needed it.

With this patch, I was able to disable apachesolr_search.module and get facet blocks with an apachesolr_views view.

David Lesieur’s picture

This would also be a first step to some refactorings that I am planning and that should lead to some cool stuff (I'm still working on my "multiple search environments" thing. :-)).

pwolanin’s picture

I don't think this really contributes to remving the search module dependency.

Also, I'm not sure it makes sense to require another module to be enabled to jsut get this basic functionality - if there is a real need to re-use the code, then maybe it should be a re-usable .inc file?

David Lesieur’s picture

Status: Needs review » Needs work

My main idea is to move re-usable code out from the apachesolr_search module to allow other modules to use it. If that code is placed in a .inc file, then other modules that might need that code won't be able to leverage Drupal's dependencies system. Ultimately, following this idea means that apachesolr_search would become quite small, only containing code that really depends on search.module.

Although the above patch relates only to facet-related code, perhaps "apachesolr_facets" is not the right name for a module whose general goal would actually be to re-use some integration code that might be too specific for apachesolr.module, but at the same time is too generic to be in a module that depends on core search.

jpmckinney’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev

More of a 6.x-2.x refactoring. Maybe even 7.x.

EvanDonovan’s picture

@David: Do you still think that this would be helpful change to make? I think creating some custom facet blocks might be helpful for me, since I want to use Solr in a Faceted Search-like way, starting with a facet block, rather than a query.

David Lesieur’s picture

I still think that this would be a step in the right direction, that is towards more modularity and a better structured API, but it looks like I have not been able to convince the module's maintainers.

jpmckinney’s picture

I think we should do it. I just don't have the time, and this patch needs work.

jpmckinney’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev

In 7.x this is maybe solved by facet_api, but keeping the issue alive for someone else to review.

pwolanin’s picture

Title: Pull facet blocks out of apachesolr_search.module » Pull facet blocks out of apachesolr_search.module (use facet_api)

Yes, the goal is to do it via facet_api,

pwolanin’s picture

Status: Needs work » Fixed

Initial facetapi integration is working.

Status: Fixed » Closed (fixed)

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

geerlingguy’s picture

So... is this documented somewhere? I noticed the blocks are missing, but had to dig down into this issue to find that the blocks were moved to Facet API. It seems that I can get these facet blocks back by installing Facet API on my D7 site, correct?

[Edit: The facet blocks can be re-enabled using Facet API (fyi for others coming to this issue)...]