Remove dependence on search.module
DamienMcKenna - June 23, 2009 - 03:39
| Project: | Apache Solr Search Integration |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
Solr provides a complete replacement for the built-in search engine, so why retain a dependency on the core search.module? Right now, if I'm reading this correctly, if you want to only use the Solr search engine and not waste the database & system with unwanted search.module calls you have to run a basically hack core to remove certain lines out of search.module (using CoreSearch.module)? Obviously, this is a bad situation, advocating hacking core is not a good thing. Why not just duplicate the functionality that's needed out of search.module and drop it completely, leaving a much cleaner system?
#1
http://drupal.org/node/405206
#2
Thanks. I searched but didn't include "fixed" in the criteria so didn't find this one. Glad to see it.
#3
We need to go ahead with the original intent of this issue and completely decouple our module from core search. Core search enforces way too many assumptions and limitations. For example, we call search_data() for no good reason... all it does is invoke our apachesolr_search_search hook. Then, we use the standard theming for core search results. This breaks if you want to display more or less than 10 results per page because the THEME layer assumes 10 items (core search has this assumption hardcoded in many places):
<?phpfunction template_preprocess_search_results(&$variables) {
$variables['search_results'] = '';
foreach ($variables['results'] as $result) {
$variables['search_results'] .= theme('search_result', $result, $variables['type']);
}
$variables['pager'] = theme('pager', NULL, 10, 0); // <---- eat that, sucka!
// Provide alternate search results template.
$variables['template_files'][] = 'search-results-'. $variables['type'];
}
?>
So I'm reopening the issue with the original title and original intent.
#4
Here's step one. Instead of calling search_data, call apachesolr_search_search directly. Eventually I'd like to refactor apachesolr_search_search to be individual functions and not related to search module's API.
#5
subscribe. still a big fan of this direction.
#6
And another baby step. Don't depend on search.module to call cron for us.
#7
Committing these two patches. More to come.
#8
Ok. These are truly baby steps. That last patch broke things so I have to pull in some of the code from search_data to compensate. One layer of extrication at a time :(
#9
How about a patch that clears the core search_* tables on cron?
#10
Damien, what would such clearing accomplish? Just "truncate search_index" and so forth? And, why would we need to do that every cron run?
Controlling core search behavior isn't really the purview of the ApacheSolr module, imo.