Solr Views returning excluded node types when they have comments

I was using one rev back on the Solr schema and an older nightly build. I have upgraded to Solr 1.4 with the latest schema from the apachesolr module just to make sure some other weirdness was not happening. I have found that the same problem exists even with everything at the current/recommended Solr release and schema.

The next thing I tried was to enable the Apachesolr block "Node attribute: Filter by content type". This had no effect because the links in the block all go to "/taxonomy/term/all" which is my current path. I disabled the block and I'm back to where I started from. To recap, my paths of /taxonomy/term/XYZ all work as expected to filter/facet the results. The path of /taxonomy/term/all (which is the same Apachesolr View) does not limit results to my specified content type. All content types and comments show up.

Getting closer. Inside of apachesolr_views_handler_filter_type.inc, function query(), I am all the way down to the bottom foreach.

      foreach ($this->value_options as $type => $name) {
        if (!in_array($type, $this->value)) {
          $this->query->add_filter($this->real_field, $type, TRUE);
        }
      }

$type as it stands comes in as set to 'items', which is my content type that I want to limit the results to and is correct. This successfully runs through the in_array and the filters are being added for all of my other content types, which in my case numbers 7. So I see $this->query->add_filter being fired off for the 7 content types that are not 'items'.

I am imagining this should all be correct so far, however the search results on the 'all' page are still coming back with nodes from one of those other content types. I'll keep plugging away, but it looks like this is further upstream from the apachesolr_views_handler_filter_type.inc file.

I also dropped a log message into function alter() to see what the query looks like, and it does have exclude arrays like this:

    [_facets:protected] => Array
        (
            [type] => Array
                (
                    [0] => Array
                        (
                            [value] => feed
                            [exclude] => 1
                        )

It has 7 of those, one for each of the content types other than 'items'. We're still in good shape.

Now I'm all the way to function execute, and looking at the $response. The response object is interesting. It has this:

"fq":["NOT type:feed","NOT type:othertype","NOT type:thirdtype","NOT type:fourthtype","NOT type:fifthtype","NOT type:sixth","NOT type:seventh"

OK so that looks good - the filter query stuff is in there to exclude those content types. Here's the interesting part of the result for the non 'items' result that came back:

{"id":"6cac9e37e71a/comment/173","nid":16823,"uid":16,"url":"http://mysite.com/othertype/16823#comment-173"

It returned a result that is tied to the comment of one of those excluded node types. The end result since the comment is tied to the node is that it shows up in the results. So I don't think my issue is tied to the use of the 'all' argument, it is the fact that the filter queries will still return comments tied to nodes that were excluded.

HAH, that's it. It only took all day to figure it out. Here's a summary.

If you have an Apachesolr View configured for "Type" to restrict results to a specific content type, the results will not respect that filter when the node has comments. I filtered on content type 'Items' but other types were showing up. See post #2 for details.

My solution, which is extremely unscientific, was to edit apachesolr_views_handler_filter_type.inc and add a new type for comments. Here's the revised function with the one line added for comments.

  public function get_value_options() {
    if (!isset($this->value_options)) {
      $this->value_title = t('Node type');
      $types = node_get_types();
      foreach ($types as $type => $info) {
        $options[$type] = $info->name;
      }
      $options['comment'] = 'Comments';
      $this->value_options = $options;
    }
  }

What that does is to add a new filter for comments. When that is unchecked in the view, it adds a new filter query of "comment" which properly filtered my results. This is probably not what is right for the main module. Thoughts are welcome in terms of a different approach.

Thanks for the reply. Would you mind posting the 1.x compatibility requirement to the project page? That little fact would have saved me about 7 hours of troubleshooting yesterday :)