I recently tried out version 7.x-1.0-beta10 on my development site to test an upgrade from the beta8. I noticed that some of the options including the "results per page" option were moved to the settings for each individual search page. While that increases some flexibility, other flexibility was removed. Specifically, the "results per page" option has changed from a text field to a drop down menu with multiples of 10. My layout requires multiples of three (I have a grid of images, not a list) and 30 is too many. I had it set to 18 before. Please consider restoring some flexibility here. I won't be pushing the newer version out to my live site because of this issue.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 1333904.patch | 1.75 KB | nick_vh |
Comments
Comment #1
nick_vhAn easy hook_form_alter will save you here? I'm convinced this is a module of maximum 10 lines maybe?
Comment #2
nick_vhIs this fixed for you?
Comment #3
vrc3 commentedSure I could do that. But I don't understand why the flexibility was removed from the module. Makes very little sense. I doubt I'm the only user of this module who needs it.
Comment #4
nick_vhIn attached patch I restored the text input of search results amount. Does this work for you?
Comment #5
nick_vhComment #6
nick_vhThis actually does make sense. Committing at once since it does not have a regression or update path necessary
Comment #7
vrc3 commentedThanks for committing this change!
I'm testing out beta11 now. I actually found that it gave me 10 results per page no matter what I did. I dug into the code and found a typo. In the function apachesolr_search_search_results, $param['rows'] should be $params['rows']. Since it's a once character error, I thought it would be faster to just describe the typo rather than build a patch. Let me know if you need me to submit a patch...
Comment #8
nick_vhThanks for that, committed it in a follow-up :)