I beleive the current search, as good as its algorytms may be, lacks a lot of usability. Nut usability for users, but for developers. Teh very fact that besides user.module and commetn module there are no modules useing teh serach hooks sais a lot.
The other HUGE problem is the limitation of search for indexing only nodes. All other entreis need to get complex fulltext search systems. Custom built for that module.

My proposal isto leave the heavy lifting in the search engine, while leaving only very easy APIs for teh developers to use.

taxonomy_search_queue() {
     //....
     $items = array('chunk' = 'taxonomy_get_description', //callback that returns a chunk of HTML
                   'index' = 'yes', //can be yes (default), no (will be regenerated each search) cache (regenerated from cache)
                   'path' = 'taxonomy/or/'.$tid, //the path where it occurs
                   'access' = some_access_rule(), //what users can see this chunk
                   'rank_multiplier' = 5);  //sometimes you want to rank higher then ordinary nodes. or other content
} 

Looks familiar? Yes, it is shaped after the menu.

Yes, I know this has a lot of downsides, but it has a lot of upsides too:

  • We can have access rules. We dont really do that now. we dont see, yet return nodes or comments even if a user cannot see parts of that content.
  • Very easy to code. all you need to beother about is is returning chunks of HTML. no need for search or counting Queries
  • we can index *anything*, not just nodes and commetns. Just look at how hard it is to get the profile data properly indexed. We can still not search in profiles!!
  • We can finally index things like help, (semi-)dynamic pages like an image gallery
  • We can somehow "indicate" the ranking. not hope for hight ranking. Some things just want higher ranking then others
  • Because it indexes HTML we can still use these great algorythms Steven wrote for ranking

So, please comment on this. Don't just shoot, but add our value, or scrap silly ideas of mine. IMO this can be done only if it gets coded. But this is such a complex thing, that using our collaborative brains should at least point the direction where that code goes.

Comments

moshe weitzman’s picture

This seems quite a bit less thought out than the current search. Are we returning HTML for indexing or for search here? Current search only returns nodes to which the user has access, so your #1 benefit is not true. Furthermore, how could a module return a value for $access when that can be different for every node when using node access permission module.

The hooks for search are not that hard to use. Its just that hardly anyone bothers because node.module handles most comment seamlessly.

Bèr Kessels’s picture

yes, comments, and nodes. but that is about all drupal cabn search for.

And no, access nodes with the sql rewrite just does not suffice. A node -any content in fact- can exist of chunks of content that have different permissions. I came across this because we used flexinode to track certain details from users/clients. if a flexinode_address was "only accessible to Foo and Bar" search would still return the nodes (yet not the actual content!) when searching for, lets say, Amsterdam.

With a little trial and error, you could abuse search to find data that was really secrt!.

And yes, I did not elaborate on the acces issue in my previous post, but it should be as follows, in my RFC:

taxonomy_search_queue() {
     //....
     $items = array('chunk' = 'taxonomy_get_description', //callback that returns a chunk of HTML
                   'index' = 'yes', //can be yes (default), no (will be regenerated each search) cache (regenerated from cache)
                   'path' = 'taxonomy/or/'.$tid, //the path where it occurs
                   'access' = array('access content','access taxonomy'), //An array with the permissions that can see this chunk, defaults to all.
                                                                                                       // Or a callback (string) to determine the access.
                   'rank_multiplier' = 5);  //sometimes you want to rank higher then ordinary nodes. or other content
}

In fact the search will be either a callback, or an array. if its an array, it will simply check for one of the access rules and allow the current user to search for that content. If it is a string, it will look for the callbback and run that, when that callback returns TRUE we are fine and may search/find that content, if not, do not return this ni the results.

moshe weitzman’s picture

Status: Active » Closed (works as designed)

search has changed a lot since this post. please rethink and reopen if needed.