Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#1 | pull-facet-blocks-out.patch | 26.29 KB | David Lesieur |
Comments
Comment #1
David Lesieur CreditAttribution: David Lesieur commentedBasically, 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.
Comment #2
David Lesieur CreditAttribution: David Lesieur commentedThis 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. :-)).
Comment #3
pwolanin CreditAttribution: pwolanin commentedI 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?
Comment #4
David Lesieur CreditAttribution: David Lesieur commentedMy 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.
Comment #5
jpmckinney CreditAttribution: jpmckinney commentedMore of a 6.x-2.x refactoring. Maybe even 7.x.
Comment #6
EvanDonovan CreditAttribution: EvanDonovan commented@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.
Comment #7
David Lesieur CreditAttribution: David Lesieur commentedI 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.
Comment #8
jpmckinney CreditAttribution: jpmckinney commentedI think we should do it. I just don't have the time, and this patch needs work.
Comment #9
jpmckinney CreditAttribution: jpmckinney commentedIn 7.x this is maybe solved by facet_api, but keeping the issue alive for someone else to review.
Comment #10
pwolanin CreditAttribution: pwolanin commentedYes, the goal is to do it via facet_api,
Comment #11
pwolanin CreditAttribution: pwolanin commentedInitial facetapi integration is working.
Comment #13
geerlingguy CreditAttribution: geerlingguy commentedSo... 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)...]