Enable searching by Views arguments

First, not sure what that commit has todo with this. That commit removes the argument only for the special field for the searching. That is the field that applies to. Searching in as the argument does not make sense at all, as it would require special logic to make it a form. Just ugly. This stuff is what exposed filters are for.

Spaces in urls are not valid urls. They are of course replace with %20 which is ugly.

And of course, referencing Google, http://www.google.com/search?q=spaces+in+urls their urls use +. And i do happen to think apachesolr_search gets it wrong. Id rather not carry that design decision through to this work.

Using an argument for the search is what I'm asking for. This feature was in the original work by drunkenmonkey, and the code is still there in apachesolr_views_handler_argument.inc This patch just makes argument searches a normal query rather than a set of filters.

Being able to use an argument for search means you can use clean search urls eg.
http://example.com/search/popularproduct

Spaces look better as '+' than as %20 of course, but that would be something that would be handled separately to this patch.

muhler the spaces vs %20 is not something that can be handled separately. Spaces are illegal url characters. In firefox, it allows the url to look like that but the reality is, it sends my%20query to the server. Firefox created a hack so it looks nice.

And Im pretty certain that you solution actually doesn't do the search. I mean, it doesn't use the dismax query. In fact, that is why I removed it: #438822-10: Search text shouldn't be an argument. Exposed filter only

The problem with having the search as an argument, is there can't be a form provided with it. Now I see there might be a use case to hide a search form from a user completely (which by the way please provide yours), but this patch doesn't solve it as it bypasses the dismax query completely . It will require a new argument handler.

By bypassing the dismax query, all the query field settings setup, any boosting (even cool things like #442320: Integratation with Solr) are ignored.

Hi Scott,

for single terms this patch makes argument searches send exactly the same call to solr as an exposed fields search.. Here are the url variables as intercepted in Drupal_Apache_Solr_Service::_sendRawGet() just before being sent to the server. (Drupal_Apache_Solr_Service.php line196 in main apachesolr module)

The code that that this patch removes was not performing the dismax query, this patch replaces that code with code that does perform a dismax query. The code that did argument based searching is still in the module, you just removed the reference to it so that it can't be accessed by Views.

When I say that spaces are handled separately I mean that it is outside of the scope of this module to handle that. That would be up to whatever form is used to direct/redirect to the View with the arguments. Actually the following all work with this patch in Firefox3.5(OSX), Safari 3.1, IE7, IE6
example.com/search/term1 term2
example.com/search/term1%20term2
example.com/search/term1+term2

The use case where exposed filters fall short and you need to provide your own form is where you want a search form on a different part of the page from the view. Eg. in the header or the sidebar. Or if you are overriding the search form as in http://drupal.org/node/409806#comment-1387282

Your right it does do that ( i misread the patch), but at the same time breaks other argument handling. The argument is designed for everything BUT the q handling. For instance, adding the taxonomy term as an argument breaks (as it adds that to the q, instead of the fl. Which means that it may appear to work, but its not being applied as a facet but rather as query term.)

Basically, your patch breaks all other argument handling.

And for ur use case, I don't see what you need here. I would create a View with display block. That block would have the exposed filter in the form. And it would, on submission goto the View's page display. This project makes that so easy.

I don't have an aversion to having the query terms in the argument, but it needs to be done right. There are plenty of ways to even generate links to search results (see all the apachesolr facet blocks, they create links and work with this project). And there are plenty of ways for Views to generate this all for you.

But I can't picture a solid use case that isn't already handled. For good examples, look at how apachesolr_facet_block is called by other modules. You can see that those other modules grab the $response, $query object from static cache and the apachesolr_facet_block uses those variables to generate accurate links to the View.

And regarding form submission, Views handles this for you. And if it fails to then something is probably wrong internally with this module

You're totally right about it breaking other argument handling. I had thought that the argument handler was just for the search, it would need a new search argument handler extending the existing argument handler to work without breaking anything.

Here's a patch which provides a new handler extending the existing apachesolr_views argument handler. Also needed an addition to the argument_part($field) function to get the links working properly in the facet block if it's used. Followed the example of the existing code used in get_url_querystring() for the exposed search filter.

My main motivation for wanting to use the search term as an argument is really just that you get clean urls. So you can perform a search by altering the url if you want, not a big deal perhaps but just a nice little touch. It might also allow better SEO if you did something like provide links to popular searches on the site, not sure if you'd get better SERPS from having terms in the url rather than the querystring but it's possible.

Another use case for Arguments Apache Solr: search is:

You want to put search results in a block, similar to related articles. "More like this" doesn't provide the same granularity of control as "search for all articles of this content type that have these words". Words are the Arguments Apache Solr: search, which I would bring in from tags. I want to use the tags to search the full content of other nodes of a specific type.

More like this doesn't do it because it seems to require searching the same set of fields (body and tags, for example) on both sides (the node you are on and the nodes in the index). I'd like to take tags from the node I'm on, and search for them in the body of other nodes of a specific type.

Would love to see Arguments Apache Solr: search back. Or a way that I can pass search terms into an Apache Solr view so that I can have more granular control over the related content I display.

Or if folks have an alternative solution, open to that too. (Not sure if I should have opened a new post for this or added it here.)

Thanks! (This request is somewhat similar, but views specific rather than apache solr specific: http://drupal.org/node/600242)