Programmatically added query parameters do not appear in the search result URL [#1784502]

Hello

we have implemented a custom query module and we have come across what seems to be some inconsistent behavior. In our hook_apachesolr_query_prepare we augment the query coming form the search form with various additional filters, things similar to

$query->addParam('fq', 'date:('.$d.")");

and

$query->addFilter('id', $id, FALSE);

which work very well and we get the correct results. However, the additional filters are not added to the URL that is returned by the apachesolr to the browser as query parameters e.g. for the above filters I would expect to see the address augmented with something along the lines of the following (depending on the values passed):

&fq[0]=(date:1821)&f[0]=id%3A1864

However, this does not happen and as a consequence if the user were to bookmark the page they would end up with a quite different result set the next time they visit.

Is this behavior intentional? It does not appear to be consistent when compared against what happens when selecting facets where the related filters actually appear as part of the query parameter string. I listed this as a bug report for this reason, but I may not be right and this could be intentional for reasons that I do not understand.

More importantly, is it possible to add the additional query parameters missing from the URL programmatically? There does not seem an obvious way to do this.

Comments

Comment #1

cpliakas CreditAttribution: cpliakas commented 14 September 2012 at 11:56

Category:

bug

» support

Hi arahamites.

Thanks for the post and the details. I am changing this to a support request, though, because I don't see why this filter should be propagated to the URL. Filters passed through the URL are meant to persist when actions are taken via the UI, whereas filters that are added programmatically are done behind the scenes and don't need the URL to persist since the logic be in place fo the modle to set the correct filter anyways. Maybe if you highlight your use case as opposed to just the technical details we can discuss ways to accomplish your goals.

If the user bookmarks the page, then I am thinking that your custom module should implement the correct logic in order to apply the same filters and display the same results. If this can't be done, then you should either implement Facet API to provide the filters to your users that will persist the data via the query string, or implement hook_url_outbound_alter() to add your custom filtering logic to search links.

Hope this points you in the right direction,
Chris

Comment #2

arahamites CreditAttribution: arahamites commented 14 September 2012 at 12:36

Hello Chris

and many thanks for the quick reply. I will explain the use case below, but first I should note that as you suggest I have tried to implement hook_url_outbound_alter() but this does not seem to have a practical effect -- without being too certain about this, it seems to me that the URL is rewritten by the apachesolr module after I change it as the path does not actually change to what I set it. I am not clear about the sequence that these things happen so please correct me if I am wrong.

Anyway, the use case is that in addition to the keyword search we need to have a couple more form inputs which we need to match exactly with specific fields of the node. So we have an "id" field in the form, and when a value is input, then the value should match the id field of the node (in addition to performing a dismax on the content). Of course we construct the relevant index for id while solr is indexing.

The only way I see to ensure that this is the case, is to add $query->addFilter('id', $id, FALSE) as described above. I would be most grateful if you could suggest an alternative.

Many thanks

--A

Comment #3

cpliakas CreditAttribution: cpliakas commented 14 September 2012 at 16:37

Anyway, the use case is that in addition to the keyword search we need to have a couple more form inputs which we need to match exactly with specific fields of the node.

OK, that helps. So in that case, this is where Facet API would normally come in. It is designed for creating filter / faceting UI's and takes care of the URL piece. The only issue is that it is a bit complex to use it with form elements right now. There are two sandboxes that you might be able to start from, and you can view them at http://drupal.org/sandbox/stevetweeddale/1776754 and http://drupal.org/sandbox/lynn/1311040. They are geared towards creating select lists, but I am confident you could change the form element to a text box. The http://drupal.org/project/facetapi_slider might also be a good start as well, as I believe it is a form element widget.

If you decide to code this on your own from scratch, you will have to implement a submit handler in order to take the data entered in your form and modify $form_state['redirect'] with your data appended to some query string variable of your choosing. There are some issues you will have to work though, but that is the technique you are going to have to use. At that point all search links will make sure your filter persists in the query string, and you can check for it in your hook_apachesolr_query_prepare() implementation.

Comment #4

arahamites CreditAttribution: arahamites commented 14 September 2012 at 22:51

Thanks a million Chris, your reply is really very useful indeed and it seems as if the Facet API way should actually work well.

All the best

--A

Comment #5

cpliakas CreditAttribution: cpliakas commented 15 September 2012 at 02:26

Status:

Active

» Fixed

NP. Please reach out if the Facet API method proves to be difficult. This is a use case that is half vetted in Facet API, so I will be curious to hear the challenges you encounter and the workarounds required to get things working properly. Marking this issue as "fixed", but please feel free to post other issues here or to Facet API as they come up.

Good luck,
Chris