Once I got over 1 million results, the current search block says 'Found 1 result'. See screenshots for my configuration. This happens only when I have more than 1 million results.

CommentFileSizeAuthor
#3 1850098-3.patch774 bytesAnonymous (not verified)
1mio-results.png12.44 KBAnonymous (not verified)
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Also, it fails to translate. I have this setup with i18n and it should have translated 'Found 1 result' into Dutch. So no only does it fail to plural, but it also fails to translate with > 1mio results.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Component: Code » Current Search Blocks

I found the problem. In CurrentSearchItemText->execute() of item_text.inc, there is a line that reads:

$count = (int) token_replace($condition, $data);

We are looking for [facetapi_results:result-count], but this has thousand separators! Solr returns the value with dots (.) as thousand separators:

(int) 1.000 = 1
(int) 1.123.123 = 1

See how it always becomes 1 if you go over 999.

A solution like this works:

$count = (int) str_replace('.', '', token_replace($condition, $data));
Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Active » Needs review
FileSize
1850098-3.patch774 bytes

Possible patch attached....

cpliakas’s picture

cpliakas CreditAttribution: cpliakas commented
Version: 7.x-2.x-dev » 7.x-1.x-dev

Solr returns the value with dots (.) as thousand separators:

Is this configured by a param set via Apache Solr Search Integration or Search API, or is it hard coded somewhere? It would be great to get that value as opposed to assuming a dot. Other than that I think the logic seems fine to me.

Bumping back to the 7.x-1.x branch so it doesn't continue to elude my radar.

Thanks,
Chris

cpliakas’s picture

cpliakas CreditAttribution: cpliakas commented
Issue summary: View changes
Status: Needs review » Needs work

Looking into this further, the value is converted to an int in the facetapi.tokens.inc file so it is already "1" but the time it gets to the execute() method therefore the patch doesn't fix the issue.

Looking into the facetapi.tokens.inc code, we are likely going to have to remove the cast to an int, handle the digit grouping separators used throughout the world (as highlighted at http://www.statisticalconsultants.co.nz/weeklyfeatures/WF31.html), and audit that the escaping of the values doesn't assume the values have already been cast to an integer.

Marking as needs work since this is a little more complex to resolve.