IMO, the dependency on search module gets in the way. For one, search.module always indexes nodes and can't disabled without hacking.

I know about coresearches module which is a nice way of saying - hack core. Core search is not worth hacking - I prefer it disabled.

Comments

JacobSingh’s picture

I think we have an issue for this already, but I don't see it.

@pwolanin: Do you know where it is?

And yes, I agree to the above points BUT it would be nice to have a *better* search framework so that users can seamlessly switch between Solr and Sphinx or back to core search without theming, etc issues.

So seeing as we don't have a better one, I'm a little reticent to move off of core search. I'm actually fine with it, but I think we should make sure we maintain compatibility.

pwolanin’s picture

hmm, I can't find it either.

coupet’s picture

pwolanin’s picture

@coupet - no, this would be an issue for just this module.

janusman’s picture

It would be great if we could come up with the different scenarios for/against dependancy on core search. here's a possible starting list:

Cases when removal of core search dependancy is good:
* Don't need core search, and will no longer have core search indexing what is already on the Solr index.
* ??

Cases when it's bad:
* D7 or later gets the Search API it deserves, and Apache Solr module would have to "go back" and integrate with that.
* Would have to duplicate functionality offered in other modules (like OpenSearch which can now provide RSS for Apache Solr results).
* ??

David Lesieur’s picture

Would it be too far-fetched to support two interfaces, one that would stand by itself, and another based on hook_search(), by refactoring some stuff into separate modules?

pwolanin’s picture

@David - that was basically my intention, since the amount of code specific to hook search is actually minimal.

David Lesieur’s picture

With #469642: Pull facet blocks out of apachesolr_search.module (use facet_api), we could have a small step done to take some code out of apachesolr_search.module, to favor its re-use by other modules such as a potential search module that would not be dependent on core search.

pwolanin’s picture

Looking at this now - a little trickier than I initially thought since we use user_access('search content') and there is various block and theme code.

pwolanin’s picture

Status: Active » Needs work
StatusFileSize
new13 KB

WIP, non-functional.

pwolanin’s picture

Thinking about htis more - it would be easier to just form_alter to allow 0 nodes indexed by core node search (thanks Jody).

pwolanin’s picture

Title: Remove dependency on search module » Allow Apache Solr to be the default, let search module index 0 nodes per cron run
Status: Needs work » Needs review
StatusFileSize
new6.27 KB

new title, patch.

Anonymous’s picture

Status: Needs review » Reviewed & tested by the community

It seems to work properly for me. :)

JacobSingh’s picture

Status: Reviewed & tested by the community » Fixed

Committed...

Accidentally let CVS but the wrong comment in with -m on the command line once, but got it in proper.

damienmckenna’s picture

Thank you for this, I was really confused why core Search needed to be used given the entire engine was being replaced. I will give the next beta a good solid thrashing on a 70k+ node site.

Status: Fixed » Closed (fixed)

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

moshe weitzman’s picture

Thanks for this. I had to make a special accomodation for this clever hack in the search index command in drush. Search for Apachesolr at http://cvs.drupal.org/viewvc/drupal/contributions/modules/drush/commands...

geerlingguy’s picture

Subscribe. (Sorry, but I need it in my tracker).