Why is the rows field only capable of values 5, 10, 15, 20, 25, 30, 40, 50, 60, 70, 80, 90, 100?
example: I want it to be 9, how do I do this?
I suggest the following change to the form declaration:

  $form['apachesolr_rows'] = array(
    '#type' => 'textfield',
    '#title' => t('Results per page'),
    '#default_value' => variable_get('apachesolr_rows', 10),
    '#description' => t('The number of results that will be shown per page.'),
  );

And I suggest the following addition to the validation of the form:

function apachesolr_settings_validate($form, &$form_state) {
/*
    ... old validations
*/
    if (isset($form['apachesolr_rows'])) {
    $rows = $form_state['values']['apachesolr_rows'];
    // TODO: Port range should be 0-65535, but 0 crashes apachesolr
    if (!is_numeric($rows)) {
      form_set_error('apachesolr_rows', t('The amount of result rows should be numeric.'));
    }
  }
}

Could this not be usefull?

Comments

janusman’s picture

Status: Needs review » Active

Before you can mark an issue as "Needs review", you need to roll a patch and attach it to one of your comments.

Functionality-wise, I don't see why not. This is how Views does it.

Putting into "active" status.

jpmckinney’s picture

Title: Results per page as text field. » Arbitrary results per page
Version: 6.x-2.x-dev » 7.x-1.x-dev
Status: Active » Needs review
StatusFileSize
new1.3 KB

Not sure why we offer a select list. Pretty safe to let people set their own values.

jpmckinney’s picture

janusman’s picture

Status: Needs review » Needs work
+++ apachesolr.admin.inc
@@ -307,6 +305,12 @@ function apachesolr_settings($form, &$form_state) {
+  if (!is_numeric($form_state['values']['apachesolr_rows'])) {

Probably we only want numbers above 0 =)

Powered by Dreditor.

jpmckinney’s picture

Status: Needs work » Needs review

I don't know, if someone sets it to zero, I assume they know what they are doing. 0 rows still gets facet data, total matches, etc. I can imagine some less common uses for 0 results. I don't think we need to hold the admin's hand too much.

pwolanin’s picture

StatusFileSize
new1.65 KB

Well, we should probably cast it to an int and make sure it's at least 0?

Also, in the real world, I've noticed pretty serious performance effects from returning lots of results, so I think we may want an upper bound like ~200 to avoid having people shoot themselves in the foot?

jpmckinney’s picture

I'm not a fan of hand-holding - it's the same reason we had a dropdown instead of a textfield. Anyway, patch looks good.

wouters_f’s picture

Status: Needs review » Reviewed & tested by the community

I have tested this - big success (borat smile).
thanks guys.

pwolanin’s picture

oops - that patch causes a fatal error by re-declaring the validate function. Committed that plus fix.

@wouters_frederik which one did you test?

pwolanin’s picture

StatusFileSize
new2.23 KB

This is what I committed to 6.x-1.x and 6.x-2.x (except for CHANGELOG piece which was different)

pwolanin’s picture

Status: Reviewed & tested by the community » Needs review
StatusFileSize
new1.73 KB

7.x patch

pwolanin’s picture

Status: Needs review » Fixed

committed

broncomania’s picture

Isn't it much better that the user choose how many search results he want to see? I think even the best admin didn't find the best value even if it's 9 or 27 results?

I just research a little bit but I didn't found any solutions yet. So maybe this is also one thing we should think about.

Status: Fixed » Closed (fixed)

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

phenaproxima’s picture

For the record, I agree with broncomania - I'd like to see this functionality implemented in a user-facing way too. Can this bug be reopened?