Would it be possible to re-enable Views argument based searching for this module? I've got a patch which fixes
apachesolr_views_handler_argument.inc
to work as a normal query rather than adding terms as filters.

Would have to undo
http://drupal.org/cvs?commit=201802
and then apply this patch to get it working.

I've used Drupal_Apache_Solr_Service::escape($term) rather than apachesolr_views_query::escape($term) as the apachesolr_views_query::escape function does phrase based searches for multiple terms.
Instead of searching for term1+term2, it searches for the phrase "term1 term2". Seems to me it's better to keep the same default settings as the apachesolr_search module, and also google etc.
Should be trivial to add an option setting to the views admin screen to enable choosing between phrase and term searching if preferred.

CommentFileSizeAuthor
#21 apachesolr_views_args.patch772 bytesrobbertnl
#20 apachesolr_views_args.patch772 bytesrobbertnl
#16 apachesolr_views-449190-16.patch975 bytesmustanggb
#8 apachesolr_views-449190.patch2.71 KBmuhleder
apachesolr_views-views-arguments.patch1.5 KBmuhleder

Comments

Scott Reynolds’s picture

Scott Reynolds commented
Status: Needs review » Needs work

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.

muhleder’s picture

muhleder commented

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.

Scott Reynolds’s picture

Scott Reynolds commented

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.

muhleder’s picture

muhleder commented

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)

exposed fields search $url from Drupal_Apache_Solr_Service::_sendRawGet()
http://localhost:8983/solr/select?fl=id%2Cnid%2Curl%2Cuid%2Ctitle%2Cbody&facet=true&facet.mincount=1&facet.sort=true&facet.field=im_vid_2&f.im_vid_2.facet.limit=20&facet.limit=20&version=1.2&wt=json&json.nl=map&q=stelrad&start=0&rows=10

argument search $url from Drupal_Apache_Solr_Service::_sendRawGet()
http://localhost:8983/solr/select?fl=id%2Cnid%2Curl%2Cuid%2Ctitle%2Cbody&facet=true&facet.mincount=1&facet.sort=true&facet.field=im_vid_2&f.im_vid_2.facet.limit=20&facet.limit=20&version=1.2&wt=json&json.nl=map&q=stelrad&start=0&rows=10

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

Scott Reynolds’s picture

Scott Reynolds commented

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.

Scott Reynolds’s picture

Scott Reynolds commented
Status: Needs work » Closed (works as designed)

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

muhleder’s picture

muhleder commented

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.

muhleder’s picture

muhleder commented
Status: Closed (works as designed) » Needs review
StatusFileSize
new apachesolr_views-449190.patch2.71 KB

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.

PeterZ’s picture

PeterZ commented
Version: » 6.x-1.x-dev

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)

bennos’s picture

bennos commented

yeah, would love to make a solr view with a taxonomy tag as argument, that performs an individual and better MLT search.

good for usability and SEO.

kenorb’s picture

kenorb commented
Status: Needs review » Reviewed & tested by the community

Tested and it's working fine.
Thanks!

kenorb’s picture

kenorb commented

One minor issue with Views-dev: #899274: Warning: Invalid argument supplied for foreach() in views_theme() in views.module on line 87

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

#9:
Would love to see Arguments Apache Solr: search back.

I was wondering about this - how can I search via an argument if I can't add "search" as an argument? A little confused. :) Would love to help test this out. Thanks!

kenorb’s picture

kenorb commented

Any progress implementing this?:)

kenorb’s picture

kenorb commented
Status: Reviewed & tested by the community » Fixed

http://drupal.org/cvs?commit=464668
http://drupal.org/cvs?commit=464676
Committed patch from #8

mustanggb’s picture

mustanggb commented
Status: Fixed » Needs review
StatusFileSize
new apachesolr_views-449190-16.patch975 bytes

#8 wasn't quite applied cleanly in #15
Which caused #899274: Warning: Invalid argument supplied for foreach() in views_theme() in views.module on line 87
Fix attached

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Needs review » Reviewed & tested by the community

Can this please be applied?

Considering that it was RTBC on #15, but the patch was badly applied, I am resetting that status.

tauno’s picture

tauno commented

#16 fixes the previous patch

brycesenz’s picture

brycesenz commented

The patch in #16 fails for me in the latest -dev version. Does anyone else have this problem?

robbertnl’s picture

robbertnl commented
StatusFileSize
new apachesolr_views_args.patch772 bytes

I made a new patch for the latest dev version (with same changes)

robbertnl’s picture

robbertnl commented
StatusFileSize
new apachesolr_views_args.patch772 bytes

#20 is the wrong file. Please use this one.

hongpong’s picture

hongpong commented

This may be related - Had an error like so:
Warning: Invalid argument supplied for foreach() in template_preprocess_views_ui_edit_view() (line 1109 of sites/all/modules/views/includes/admin.inc).
in all the views edit screens. it stemmed from something involving the apachesolr_views view handler and apparently a missing javascript file.

mustanggb’s picture

mustanggb commented

This one keeps catching me out and it stems from a broken commit
Can we please get this in ASAP?

muhleder’s picture

muhleder commented

Confirming that the patch from #21 corrects the broken commit, and applies to the current dev.

The broken commit means that the argument is added to hook_views_plugins rather than hook_views_data.

brycesenz’s picture

brycesenz commented

Confirming that this patch works for me as well.

csedev’s picture

csedev commented

Works for me

dstuart’s picture

dstuart commented
Assigned: Unassigned » dstuart
Status: Reviewed & tested by the community » Closed (fixed)

Have commited #8 then patched with #21. Hopefully this should be it

moonray’s picture

moonray commented
Status: Closed (fixed) » Reviewed & tested by the community

Looks like #21 never got committed.

shaneonabike’s picture

shaneonabike commented

Yeah I'm still getting this error as well? Could we apply this patch in the dev? Thanks

mgriego’s picture

mgriego commented

Agree with the last two posters. I had to apply #21 by hand to the latest -dev version.

dstuart’s picture

dstuart commented

I have a little time tomorrow so will try and hit the bug queue. If there is anything else that is urgent just give me a shout

Cheers

Dave

dstuart’s picture

dstuart commented

Ok I think its in now. I was committing to the 6.x1.x branch as opposed to HEAD which I though was old legacy. I going to go back and look at all my other projects to see if I have committed in the correct place. Think I need to invest in some self teach git books!!

dstuart’s picture

dstuart commented
Status: Reviewed & tested by the community » Needs review
mustanggb’s picture

mustanggb commented
Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.