Solr_Base_Query->parse_filters() causes filters to disappear when using or search on taxonomy id's

I can confirm that the bug exists in the dev release, too. Good catch.

This is a pretty big WTF no?

This should already be fixed via: http://drupal.org/cvs?commit=466956

Well I was running off "1.1.4.40.2.32" (i.e. http://drupal.org/cvs?commit=466956) and it is still a problem

Here is my example situation
In $pos = strpos($this->filterstring, $filter['#query']); you always compare against $this->filterstring
Which for me is "tid:3 tid:11 tid:1 tid:12"

The first $filter['#query'] compared is " tid:12" which correctly returns "18"
The second is " tid:11" which correctly returns "5"
The third is " tid:1" which wrongly returns "5"
The fourth is "tid:3" which correctly returns "0"

Ah, I see - it is related to but not the same as the other bug.

Here's a possible 7.x fix, which I think will also apply to 6.x. I prefer strpos() if possible since it's much faster.

Found another bug at the same time while writing a unit test - we do not want to use the get_fq() function to generate the query string, since filters may be groups and hence re-ordered.

committed that to 7.x

Here's a 6.x-2.x version of the patch.

Fantastic job, thanks for following this up

Is the patch working for you?

R'd previously, have now T'd, working as expected

committed to 6.x-2.x, but the 6.x-1.x version needs to look slightly different I think.

Untested.

I'm trying to recall - I think there was a difference in 6.x-2.x vs. 6.x-1.x that means the change to get_url_queryvalues() is not needed. Likely it will not hurt, but not needed.

Side note, for good or ill, the change I made to 7.x-1.x/6.x-2.x means you won't see subqueries reflected in the URL. My thinking there was that the code doesn't handle parsing them from the URL, so there is no way we should be showing them.

However, I think if we switch to a ?f[]= querystring for each fq, we might indeed want/need to be able to parse them from the URL.

The is just the latter part of the patch above - I think that's all that's need to fix the bug in 6.x-1.x.

The previous patches fixed two bugs. The other bug you described as "Found another bug at the same time while writing a unit test - we do not want to use the get_fq() function to generate the query string, since filters may be groups and hence re-ordered." Does that bug not exist in 6.x-1.x?

That bug does not existing in 6.x-1.x afaik, since we don't do the filter grouping which is part of the OR facet logic.

Applied #15 to 6.1