add a MoreLikeThis handler and use it for mlt queries

looks like a good idea - this handler is not available in the standard config file?

do we need to set this to fasle?

mlt.match.include

Note that I added this commit yesterday: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/apachesolr/...

MLT now at least works like it did.

ok, I seem some minor fixes needed - e.g. we should use id and not nid.

some important changes - note, for example, that the schema changeed to 'taxonomy_names'

we should also use the id when searching and the url to make the link.

this seems to work - committing to 6.x, but open to follow-up patches.

I get this sort of error when I create a new node:

warning: end() [function.end]: Passed variable is not an array or object in sites/all/modules/apachesolr/contrib/apachesolr_mlt/apachesolr_mlt.module on line 78.

Since I imagine the new node is not yet in the index.

committing to 6.x

hmm, the current mlt code does not obey node access - e.g. you can get a 403 on a node page but the more-like-this block will still appear.

here's a patch just to suppress the block when the user cannot view the current node.

We also need to add in a hook so that we can add node-access information to the query as fq parameters.

A little better - committing this but still needs to have the query altered to add fq params.

really needs to be marked open - basically for this (and the attachements module) we really need a central or common hook to call to add stuff like node access filters.

Perhaps with parameters for the query handler ('mlt', 'standard', 'dismax') as well as the module name or some such? E.g.

drupal_alter($query, 'mlt', 'apachesol_mlt');

Ugh... this seems messy. I'd be more inclined to not make this a hook until we need to, but rather just let other modules which are operating outside of the context of the main search query hardcode in their requirement of nodeaccess since it is going in the core mod.

I imagine an abstraction later, but this one seems messy to me. Too much implementation details to keep track of.

What do you think?

I guess this is also related to folding sub modules into the core one (still not happy about this). If we do so, how can other modules use the implemented hooks in nodeaccess when it no longer implements a hook?

The hook would be an apachesolr_search module hook, maybe that pulls in a .inc file (so we can re-use the code).

still a problem?

It seems we already have the basic 'modify_query' hook in here, so node access controls should work. Committing this very minor cleanup patch.