Make indexing comments optional.
robertDouglass - September 17, 2009 - 15:52
| Project: | Apache Solr Search Integration |
| Version: | 5.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | claudiu.cristea |
| Status: | closed |
Description
Add a variable, apachesolr_index_comments_with_node (TRUE | FALSE) which controls whether or not comments are globbed onto nodes during indexing. There is no UI for this, so at this point you have to use $conf in $settings.php to set the variable.
#1
Committing this.
#2
#3
I just Ran into this problem and did something more hack-ish because I needed on a per node type.
Would you consider switching this to a per node type setting?
#4
Hmm. I'd consider it. Maybe you can roll a patch against this commit?
My next step is to create a module that indexes comments as documents so that you can search for comments exclusively.
#5
Indeed - per node type does seem like the appropriate level of selection.
For 2.x, we should think about several possible options, including:
Depending on getting the highlighting right, some variant of #2 would be good since it would allow you to search node only, node + comments, or comments only either as user options or admin options without reindexing and without duplicating the other meta data.
#6
To piggy back off of 2, you could then specify a mlt that only looks at the node body, instead of body + comments
Which would be a big win I think.
#7
Ok. I agree with all that. I don't think, though, that we want to pollute our interface with that level of complexity, and we also don't want to automatically implement every strategy because it causes index bloat. So I'm open to ideas about how we can architect it to be lean and mean, but give the admin the right amount of flexibility without overwhelming. Suggestions?
#8
Here's a patch for 1.x for per-type exclusion.
#9
with README change
#10
+ code comment
#11
committed #10 to 6.x-1.x
#12
needs to be ported to other branches
#13
Committed to DRUPAL-6--2
#14
Here's the patch against 5.x-2.x-dev
#15
Committed to CVS in #278734
#16
Automatically closed -- issue fixed for 2 weeks with no activity.
#17
I had this problem. And couldn't solve it for a long time lol...