This needs to be looked at. The way sorts are handled in apachesolr project are a bit hard to handle as well. Need another array structure to represent the sorts and then to build them. Also need some logic to produce a unique $_GET param to be used with the sorts. (with filters, Views handled this, for "exposed" sorts we going to need our own magik).


Scott Reynolds’s picture

Please note this is just the block. Sorts work properly though the Views Interface, just the sort block doesn't work.

Scott Reynolds’s picture

Title:Apachesolr Sort block doesn't work» Apachesolr Sort block doesn't integrate with this module
momendo’s picture

I can confirm the "Sort By" block shows up empty here.

domidc’s picture

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

Any luck a patch exists somewhere to enable this?

torgosPizza’s picture


dpalmer’s picture


torgosPizza’s picture

Any update on this? Does anyone have this block working? Would love to have sorting enabled this week. Started to take a look at it myself, but I'm a noob when it comes to Views (and solr, so combined it's a double whammy).. any help is appreciated.

nally’s picture


nally’s picture

I'm not sure what the correct approach here would be, but I've observed that setting a Sort Order and then Exposing it (within Views) doesn't add the sort to the "Apache Solr Core: Sorting" block.

My route around for now has been to do that (to expose the sort via the usual Views controls) and then (once exposed) a block will be defined that collects whichever things have been exposed (filters, sorts, etc.)

I know that this is not the solution that this thread seeks, but I include my experience here because of the lack of description for others who follow this way.

BeaPower’s picture

Is there anyway that this will be implemented?

i.gajic’s picture

It's been over year and half since this issue is reported. Will this issue be fixed in reasonable time? Is there any 3rd party solution to this issue ?

Amy_M’s picture


dirtysteak’s picture

Priority:Normal» Major

Changing priority to major because this causes a complete loss of functionality from the standard Apache Solr module...its killing me that we can't use the two together!

We would be willing to put up $150 towards getting this fixed with a patch, anyone else willing to pony up if it will spur development??

LetUsBePrecise’s picture

We are also facing same problem. Not sure what can be done here. Any help on this please.

geoffreyr’s picture

Status:Active» Needs review

I've had a go at patching this to try and make it work in at least Views 3.

Here are the changes I've made so far:

  • The format of apachesolr_views_query::get_solrsort() has been changed to work properly with apachesolr's implementation of hook_block. Instead of returning an array of sorts, it returns the first sort definition with #name and #direction properties. Since Solr's query requests sorts to be comma separated, I add any additional sort definitions onto the end of #direction with comma separation. (It's not particularly clean, but it seems to work for now and can always be improved on later.)
  • Seeing as apachesolr_views_query::get_solrsort() only returns a two-item array, it now implodes with ' ' instead of ','.
  • title and name now get mapped to sort_title and sort_name, to ensure sorting on titles and authors works.
  • apachesolr_views_query::get_url_queryvalues() now returns a 'solrsort' query value to ensure that URLs in the block get populated correctly.
  • apachesolr_views_query::add_sort() now defaults to a single sort.
  • The $_GET['solrsort'] variable wasn't working, so that's being handled through an apachesolr_modify_query hook.
  • My own implementation of this module allowed certain sorting options to be left out of the block. The $skip variable in init() allows certain sorts to be left out of apachesolr_views_query->_available_sorts. Unfortunately, I haven't worked out how to make it configurable per view yet, and I'm not willing to hardcode anything in here.

Unfortunately, this implementation doesn't allow for multiple sorts, so there's definitely room for improvement. (I'm not sure whether apachesolr module's sort block allows for multiple sorts, could anyone shed some light on this for me please?)

geoffreyr’s picture

new4.21 KB

...and here's the patch. Sorry about that.

picxelplay’s picture

apachesolr.module's sort block doesn't allow multiple sorts either. Everything seems fine to me.

picxelplay’s picture

Any progress yet on getting this to work 'per view'?

smd_ksu’s picture

How do you remove certain sorts from the block now that it appears? I tried the code below with no luck.

function apachesolr_cck_search_apachesolr_prepare_query($query, $caller) {
ShaneOnABike’s picture


macjules’s picture

benschaaf’s picture

This patch fails on the latest DEV release, and this is very much still an issue.

patching file apachesolr_views.module
patching file
Hunk #3 FAILED at 281.
Hunk #4 FAILED at 473.
Hunk #5 succeeded at 747 (offset 3 lines).
patch unexpectedly ends in middle of line
Hunk #6 succeeded at 772 with fuzz 1.
2 out of 6 hunks FAILED -- saving rejects to file

I am going to try to patch this manually, as the patch is quite old now.

Has anyone been able to get this to work? Thanks!

toemaz’s picture

Applied the patch on an old dev release and things worked out for me. Don't have the latest dev running, so I can't make a new patch for now.

torgosPizza’s picture

Version:6.x-1.x-dev» 7.x-1.x-dev
Issue summary:View changes
Status:Needs review» Active

This problem appears to still exist in 7.x as well.

Changing statuses to reflect this. If anyone has any working solutions, I'd be happy to test them as this is pretty critical.

MiroslavBanov’s picture

Priority:Major» Minor
new860 bytes

Well, the integration of apachesolr_views with apachesolr_search is problematic, Apachesolr module implementation of sort is also problematic.

I can suggest one of two options:

  1. You can try using exposed sort handers instead, I think that most of the functionality should be achievable that way.
  2. Here is a patch/hack that will fix it, but it is preventing views sort handlers from working. If you are not using them, it should be sufficient for your purposes.

I'm demoting this to minor, because the focus here is *views* implementation to be solid.