Most everybody agrees that Drupal search is lacking in some ways. Two of the main problems are the lack of support for multiple keyword searches and the lack of real fuzzy intelligence when evaluating keyword matches. This is, of course, a huge programming task, and Drupal programming resources are generally scarce and going to really important issues like permissions, flexinode, themes and features that are distinct to Drupal. Many people have ventured to tweak the search results, but I think that the problem would best be solved by using an existing external solution and abstracting the search in the Drupal core to an unimplemented API. Supporting pluggable search solutions through contributed modules and a well defined search API would open up a world of freedom and result in high quality search solutions.
One external package that I know of is PHPDig (http://www.phpdig.net/), and after installing it and testing it for a day, I think it could be used as a complete search solution for Drupal. It produces nice search results that don't violate the principle of least surprise, and the results can be optimized both through the administration interface and through the inclusion of tags that inhibit indexing.
Potential problems with this approach are the inherent redundancy of a Drupal site (many roads to Rome) which tend to clog the results a spider produces, the dependence that PHPDig has on using HTTP (it would be nicer if it could search the database), the need to install 3rd party (non Drupal) software, and in 4.4.1, the irritating fact that the embedding the PHPDig scripts and includes causes database connection conflicts.
The benefits, however, are great: we don't maintain search algorithms, development of the search code continues and is done by people who have an expert interest in the subject, other solutions can be plugged in (assuming the Drupal API is flexible enough), and no star Drupal developer has to spend 2-3 weeks rewriting the existing search.
As I am still relatively new to Drupal, and am nearly drowning in work from my day job, I cannot volunteer to lead this project, but I wanted to add my 2 cents, for what it is worth.
cheers,
Comments
(signature)
- Robert Douglass
-----
visit me at www.robshouse.net
PHPDig
I took a quick look at the PHPDig code and I'm not really impressed. Aside from the fact that most of it is built to spider, not to index, the code itself doesn't seem very clean. When a search function in a 'lib' subdir needs to occupy itself with checking for magic_quotes, a bell should ring.
I'm sure PHPDig contains several nice features, but overall it seems hard and not a good idea to include it in Drupal.
Fine - then another
Whether PHPDig or PHPCoolSearch or whatever, my argument was more for the abstraction of this functionality. We could start by moving the current search stuff to a module, which could in turn be replaced by user contribs later. I agree about PHPDig code, horrible looking. Not even formatted nicely. It works pretty well, however, aside from not detecting redundancy very well. And it gives enough configuration power that one can tailor it to behave well with Drupal sites. There is a difference between including something with Drupal and allowing something to work with Drupal.
Are there other PHP search packages that you like better?
- Robert Douglass
-----
visit me at www.robshouse.net
More on search...
Same here, I looked into it as well... Just too messy to deal with. We do need some better method for searching that drupal currently has. I settled on the mySQL based tripsearch module for what I needed. It seems to work as well as the drupal search for up to 7000 articles that I have in my dB without the overhead or running the cron script to index the search. We do need to figure out some better method for creating a search engine that works better with drupal. Look at some better methods/algorithms for searching I guess than we currently have.