Values excluded by a filter show up in the Current search block.

For example, when using the "Apache Solr: Type" filter in the view and setting it to not allow the Story type, "Story" appears in the Current search block.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Scott Reynolds’s picture

Unfort, the way the facet blocks work for node type for instance, the query has to say NOT Node_type1 NOT node_type3 instead of saying only node_type2.

This introduces a rather weird strange things to happen.

Probably going to have to fix that facet block in the apachesolr project so we can remove this ugly hack. Do something like count of distinct node types return from the query != 1 then we will have an unclick link. Maybe something. I know I took a stab at it awhile back, it is quite hairy

miiimooo’s picture

Version: » 6.x-1.x-dev

+1

Anonymous’s picture

So what can we do to remove these unwanted links ?
Thank you.

tinker’s picture

Status: Active » Needs review
FileSize
2.09 KB

@Scott Reynold, Can you please check over the attached patch and let me know if the logic is flawed? I did not see why the query would require a 'NOT' statement. The patch removes the operator_options() function and uses the default 'in' and 'not in' conditions provided by views. It then passes it to query->add_filter() using $exclude as the negate filter condition when needed.

I have tested this with apachesolr 6.x-2.x-dev and it is working properly in filtering the results using both conditions. e.g 'type is one of page' or 'type is not one of page'.

This patch only partially fixes the issue that @David Lesieur reported. e.g. if 'type is one of page' is used then only type 'page' appears in the filter block and not all the other types that were previously excluded. I think that the apachesolr block also has a bug in that negated filters are not indicated as such but thats another issue.

alibama’s picture

Well this certainly is a good step. Tested against the latest dev version for 6.x and am incredibly grateful that it seems to be clearing up the mess... however it appears that there are some serious issues here = breaks when more than one content type is selected = if two content types are selected it seems to treat them as an and statement instead of an or, since no content is both it busts.

tinker’s picture

@alibama: Yep you are right. This only works with one type because the default filter operator is AND. This is not a difficult fix. The add_filter() query needs to be reworked to use add_sub_query(), if more than one value is selected, which can specify the OR operator. I currently have very little spare time so will not be able to patch for a while.

The code will be something like this if anyone wants to take a stab at it:

    if ($this->operator == 'in' && count($this->value)>1) {
      $sub_query = apachesolr_drupal_query('');
      foreach ($this->value as $value) {
        $sub_query->add_filter($this->real_field, $value);
      }
      $this->query->add_subquery($sub_query, 'OR');
    } else {
      // 'not in' operators
      foreach ($this->value as $value) {
        $this->query->add_filter($this->real_field, $value, $exclude);
      }
    }
alibama’s picture

Hi Tinker - thanks for the heads up, i'm definitely going to give this a go in a bit. To anyone testing this patch it is worth noting that it seems to break any search where the node type is NOT exposed...

GaxZE’s picture

A work around for this - if i understand it correctly.

Your after a apache solr views listing which filters just 'blog' content.

However the blog filter for apache solr ends up just populating the Current search with all your other content types.. aka its not working.

The work around i've used is using arguments.

Create content type argument. Then just provide it with a default value.. in this instance blog.

Then it should just be down to managing your blocks.

Hope it helps somebody.

Gary