| Project: | Apache Solr Views |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I was getting a php error when I enabled the current search block whilst using a apachesolr view. Can't remember the exact wording but it was something about apachesolr_views_queryhaving to be compatible with Drupal_Solr_Query_Interface.
Looked at apachesolr_views_query.inc and found the class implemented Drupal_Solr_Query_Interface, so I guessed that it would need the same amount of variables.
Also noticed whilst I was trying to get arguments working that one of the following lines also appeared to have an error was calling $this->facets() as a function ($this was $view->query), and also that the get_filters() function wasn't actually returning anything.
This patch fixes those 3 issues, sorry to not break it all up but seemed silly to provide 3 patches for one small block of code.
FWIW I also had to alter the value of $view->real_field to get arguments working, but that is a separate issue that I don't have a proper fix for. Exposed filters work ok, but I had already built a platform using views arguments to perform the search.
| Attachment | Size |
|---|---|
| apachesolr_views_get_filters.patch | 568 bytes |
Comments
#1
Here's an updated patch which fixes the 'remove filter' links that appear in the 'current search' block. The search term appears as a filter link that can be removed, might be useful? I know I use search in that way from time to time, once I've found a category/facet I'm interested in
Also fixes the 'filter by taxonomy' blocks, should get both the links to add a taxonomy filter and remove a taxonomy filter working. Adds a filters=tid:181+filters:24+tid:7 component to the querystring.
This is all when the search is being performed using a views argument, haven't tested against an exposed filter (which seemed to be the only working search method using the module as is). It should be noted that in order to be able to search by argument you will have to change
$data['apachesolr']['text'] = array(
to
$data['apachesolr']['body'] = array(
in apachesolr_views.views.inc around line 273
but this will break handlers for the body fields. Otherwise solr will be querying the 'text' field which doesn't exist in the standard schema.xml.
#2
I am purposably avoiding processing the $_GET. Cause that won't work if you change your exposed filters settings.
The real problem lies with apachesolr_search.
#3
Do you mean like a namespace clash if you labeled one of your exposed filters 'filters'. Was thinking about that, could use 'apachesolr_views_filters' instead in the querystring eg.
apachesolr_views_filters=tid:181+filters:24+tid:7
Assume otherwise you'd have to do it with sessions?
#4
no see Views handles the $_GET for us via exposed filters. I don't want to hardcod 'filters' into the parsing as it could be something different.
in get_url_querystring() function it uses the exposed filters from the View to figure out facets are applied. $_GET[$filter->options['expose']['identifier']] is the applied exposed filter. Views handles this for us, need to leverage that and not hardcode stuff. As users can use different identifiers then 'filters'.
#5
in regards to arguments not working, give the latest cvs up a try. Args work for me. They power my facet blocks on this project.
#6
That makes a lot of sense. Would have to change what I've done to use views filters for both creating the filter links and interpreting them then.
#7
Just tried the latest CVS head on a test install I have. Fresh copy of Drupal 6.10, patched copy of views 2.5, apachesolr-dev from apr 17th. Fresh solr install using schema and config from apachesolr module.
Still getting the arguments not working unless I alter apachesolr.views.views.inc from
$data['apachesolr']['text'] = array(
to
$data['apachesolr']['body'] = array(
This changes $views->real_field to be 'body' instead of 'text'. If you grab the get request that is sent off by the _sendRawGet() function in Drupal_Apache_Solr_Service.php in apachesolr module then you see the request is
http://localhost:8983/solr/select?fl=id%2Cnid%2Curl%2Cuid%2Cnid%2Cnid%2Ctitle%2Cnid&facet=true&facet.mincount=1&facet.sort=true&fq=text%3Atest&bf=recip%28rord%28created%29%2C4%2C1%2C1%29%5E200.0&version=1.2&wt=json&json.nl=map&start=0&rows=10The fq=text:test section is requesting solr to search for the string 'test' in the indexed 'text' field, except that with the standard apachesolr schema.xml, text is not an indexed field, so no results are returned. You can change the views 'table' to 'body' as above(which is an indexed field in the standard install), but this will break some of the other body handlers. Personally I'm using a custom search field in schema.xml, so I can change the name to my field name and it's searching that field nicely for me.
Think we need to be searching titles and taxonomies etc. as well which doesn't seem to be happening at the moment, probably because the search is by specific field, if we add the general 'q=searchstring' component to the get request then the titles etc are searched. Not sure how to change the apachesolr_view code to get that working, but it is going to be something I'll have to do over the next month or so.
#8
ur really doing something strange, here. the 'text' field is a fake field. It isn't part of the fq section. its sets just the q which doesn't ever line up with a part of the schema. the q is part of a disminmax query. the handler itself does a $this->query->set_query($this->value). that means it just setting the q and doing nothing else. And it isn't an argument it is just a filter. that defaults to exposed.
you have me terribly confused. How did fq=text get into that query? Its never added as a filter via $query->add_filter().
#9
fixed current search block: http://drupal.org/cvs?commit=201794
#10
I'm getting this when I try to use the 'Apache Solr:Search' argument to do the searching in the View. I'll attach an export of the View just for clarity.
This is on a fresh Drupal install with just apachesolr, apachesolr_views and views modules, set up just for testing.
I wonder if anyone else using arguments in the view to power the search could check if titles are being searched?
#11
ahh i see fixed now. You should not use that argument. you need to use the exposed filter. see: http://drupal.org/cvs?commit=201802
#12
#13
Automatically closed -- issue fixed for 2 weeks with no activity.