Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Before deploying apachesolr on a site I wanted to pregenerate the search index. I assumed that this would be possible to simply install apachesolr (the framework) and let it index the site.
Turns out this isn't the case. The "send to index" feature claims to send stuff but no POST requests show up in the solr logs. I need to install the apachesolr_search module to get it to index too.
This seems like a bug to me.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 1062232-batch-generic-9.patch | 3.88 KB | pwolanin |
Comments
Comment #1
pwolanin commentedThis is expected in 6.x - the indexing code is actually invoked by apachesolr_search
Trying to refactor in 7.x
Comment #2
killes@www.drop.org commentedThis is a %&(=)(&/TRE&/( broken UI: the option "Index queued content" should not be available if there's no use in using it.
Comment #3
jpmckinney commented@killes: Solr is capable of storing anything. apachesolr_search adds nodes to Solr. But someone else can write another module that adds other types of data to Solr.
Right now, apachesolr explicitly references "apachesolr_search" in apachesolr_batch_index_nodes in apachesolr.admin.inc, and "apachesolr_search" is a default argument to apachesolr_current_query and apachesolr_static_response_cache in apachesolr.module.
If we can refactor those references out, then apachesolr will be independent of apachesolr_search, as it should be.
However, for @killes, it will remain the case that apachesolr_search must be enabled to index nodes. Maybe you are suggesting that there should be an apachesolr_search_ui that adds on all the search (non-indexing) features, or that node indexing should be moved to apachesolr.
Comment #4
killes@www.drop.org commentedThe UI as it is now is confusing as it implies I could index nodes by using the given option. Given that 97% of people will use apachesolr to index nodes, this is quite likely to confuse others too.
The feature I was looking for was a way to index my site without showing the new UI yet, ie without explosing the "apachesolr" tab on the standard search page. I would simply move the user visible UI to apachesolr_search and the indexing to apachesolr.
Comment #5
jpmckinney commentedYes, we should do something like that. However, most users enable both modules at the same time, so there is not that high a likelihood of confusion currently.
Comment #6
jpmckinney commentedComment #7
pwolanin commentedComment #8
jpmckinney commentedNote references to apachesolr_search from apachesolr mentioned in #3.
Comment #9
pwolanin commentedHere's an untested starting patch for 6.x-2.x (probably need the same in 7.x or it will be solved via multientity code)
I'm not see any similarly bad code mixing in 6.x-1.x - can you double check. I think the default argument is less of a worry, though idelaly we'd do away with it.
Comment #10
pwolanin commentedComment #11
jpmckinney commentedNoting that we should mark this as "patch (to be ported)" in case #456420: Add Batch API support for rebuilding indexes gets committed to 6.x-1.x
Comment #12
nick_vhMarking this as 7.x since we ran into the separation issue
The indexer problem would be resolved whenever #966796: Separate indexer for multiple entity types will be commited.
Comment #13
nick_vhMarking this as a duplicate of #966796: Separate indexer for multiple entity types since that is a very good attempt to solve these dependencies. No need to have two similar threads running :-)