Allow for non key:value filter queries

But maybe the filter name could be _query_ because when you want to filter with other fields you need the name fq=_query_:"{!geofilt sfield=coordinates pt=33.820354,-118.266182 d=10}" filtername1:value1 filtername2:value2 ...

Also _query_ could be the name like i said in #2 but we need to put !geofilt into quotation marks to work correctly.so maybe?

return $prefix . $filter['#name'] . ': "' . $filter['#value'].'" ';

Can't quote generally, since you might have a paranthesized query, right?

@pwolanin yes ... because range fq doesnt work with quote for example.You have the reason, excuse.

Maybe only when the name is _query_ ?

   if ($filter['#name'] != '_query_') {
      return $prefix . $filter['#name'] . ':' . $filter['#value'];    
    } else {
      return $prefix . $filter['#name'] . ':' . '"' . $filter['#value'] . '"';
    }

we don`t need nothing for double quotes because is implemented exuseme today i had time to check correctly the code.

    // If the field value contains a colon or a space, wrap it in double quotes,
    // unless it is a range query or is already wrapped in double quotes or
    // parentheses.
    if (preg_match('/[ :]/', $filter['#value']) && !preg_match('/^[\[\{]\S+ TO \S+[\]\}]$/', $filter['#value']) && !preg_match('/^["\(].*["\)]$/', $filter['#value'])) {
      $filter['#value'] = '"' . $filter['#value'] . '"';
    }

I have been trying to integrate SOLR3.2 proximity search with Drupal 6.x & apachesolr 1.5
would the adjustment be similar in 6.x, should I start a new issue thread

@jimijamesi Yes its similar you can try for example in you hook_apachesolr_modify_query something like $query->add_filter("_query_", '{!geofilt sfield=location pt=36.7344685,-6.43353209 d=10}');
like this you add parameters to q.alt in D6 case.

And about the current issue i think we dont need a patch here because we can add what we need in D7 also using the same query syntax.

#9 works for me with one correction: the value part needs to be surrounded by double quotes, so it should look like this:

$query->add_filter('_query_', '"{!geofilt sfield=location pt=36.7344685,-6.43353209 d=10}"');

I have a site with multiple content types. Some are location enabled nodes as well as non-location nodes (articles/stories)

When implementing this solution solr only returns nodes that have location info.

How could the code be adjusted to return both location and non-location nodes

Has anyone experienced this problem?

So using _query_ this works with no code change needed?

can someone add this to documentation?

Added http://drupal.org/node/443986 .

I guess I can close this since it is working as designed, correct me if I'm wrong and reopen when needed.

I have reopened as I am having a similar but different problem.

When trying to add complex filters the addFilter strips my query

((bundle:(event) AND im_vid_99:123) OR (bundle:(exhibition) AND im_vid_23:989))

Ends up as

(:bundle:(event))

I can try to work around this with the _query_ suggestion above but I was trying to set this in the custom filters section of the apachesolr pages.

Could we look into adding a _raw_ keyword option that allows us to set whatever we like in the fq, this seems overly restrictive and other than removing the protected option from the $params field I can't see a work around

Regards,

Dave

How do you add this param? Using the UI or in code?

See if this solves it?
In the custom textfield you can add _query_: in front of your custom query so it will validate, and it will remove the _query_: part afterwards.

Turns out the _query_ works it was apachesolr_search_conditions_default that needed some work it seems as though $search_page->settings['fq'] is stored as a array

Attached is a patch

+++ b/apachesolr_search.moduleundefined
@@ -753,9 +753,14 @@ function apachesolr_search_conditions_default($search_page) {
   if (!empty($search_page_fq)) {
-    if (!empty($path_replacer)) {
-      // If the manual filter has a % in it, replace it with $value
-      $conditions['fq'][] = str_replace('%', $path_replacer, $search_page_fq);
+    if(is_array($search_page_fq)) {

Now we check if $search_page_fq is not empty and if it is an array. We could do this in 1 if.

Also str_replace supports arrays

subject
The string or array being searched and replaced on, otherwise known as the haystack.
If subject is an array, then the search and replace is performed with every entry of subject, and the return value is an array as well.

so the foreach should disappear I guess.

sorry missed this. foreach could disappear for path_replacer but items need to be added individually to the fq else you get a nesting issue that is causing the query not to work

is this ok can push this to dev?

dstuart, please provide a valid patch file so at least the testbot is happy :-)