Bug 2422 - Using QueryParser: Cataloging searches with more than 1 page results show blank pages after page 1
Summary: Using QueryParser: Cataloging searches with more than 1 page results show bla...
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: PC All
: P3 major (vote)
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
Depends on:
Blocks: 12742
  Show dependency treegraph
 
Reported: 2008-07-30 03:23 UTC by Chris Cormack
Modified: 2020-11-30 21:44 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Attempt to fix (4.51 KB, patch)
2016-06-02 06:11 UTC, Nicholas van Oudtshoorn
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:51:00 UTC


---- Reported by debra.denault@liblime.com 2008-07-30 03:23:27 ----

When you do a cataloging search in Howard County's database (email me for details)on terms that produce more than 1 page of results (try Patterson or directory) when you try to navigate to the second page of results or beyond, you are given a blank page. HC is on 3.00.00.095.

I tested this on other sites and it seems to behave correctly (ISLC's test db .. they are at 3.00.00.101)

The only difference I saw between the two was that ISLC's had record in the reservoir where none of HC's searches did? Don't know if that is relevant or not.



---- Additional Comments From gmcharlt@gmail.com 2008-08-04 14:11:23 ----

Cannot reproduce in current version of Koha, and the affected pagination bar was fixed by a patch made on July 10th.  A version upgrade should solve the problem for the customer.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:51 UTC  ---

This bug was previously known as _bug_ 2422 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2422

Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was debra.denault@liblime.com.
CC member debra.denault@liblime.com does not have an account here
CC member jmf@liblime.com does not have an account here
CC member rch@liblime.com does not have an account here

Comment 1 Nicholas van Oudtshoorn 2015-06-11 08:41:31 UTC
We've had this issue on both 3.18 and now 3.20. Doing a search that brings up pages yields the first page of results. But clicking on another page takes you to a dreaded "No results found page". It seems that the browser (Firefox, if it helps) seems to be thrown by what's in the query_cgi parameter. For instance, this link to the second page - http://library.pbc.wa.edu.au/cgi-bin/koha/opac-search.pl?q=bible%20theology%20%23relevance_asc&offset=20&sort_by=relevance_asc - doesn't work.

I've fixed it by adjusting the file , changing very instance of
   [% query_cgi |html %]
to
   [% query_cgi |html |replace('%23.*', '') %]

The generated link - http://library.pbc.wa.edu.au/cgi-bin/koha/opac-search.pl?q=bible%20theology%20&offset=20&sort_by=relevance_asc - now works as expected... It seems that this removes the sort order from the query - which is fine, since we put it in again.

Thoughts? I'm not sure modifying page-numbers.inc is the best place to be doing this...
Comment 2 Jonathan Druart 2015-07-14 12:24:50 UTC
Nicholas,
This sounds really bad. I don't reproduce the error, could you please give us more details?
Comment 3 Nicholas van Oudtshoorn 2015-07-15 00:16:54 UTC
Hi Jonathan,

I'd be glad to - anything in particular that I can provide? I've got the fix from comment 1 running live (for obvious reasons), but can set up another instance to try and replicate it, or even disable our temporary fix and send through some logs from "in the wild"....
Comment 4 Jonathan Druart 2015-07-15 07:14:14 UTC
(In reply to Nicholas van Oudtshoorn from comment #3)
> Hi Jonathan,
> 
> I'd be glad to - anything in particular that I can provide? I've got the fix
> from comment 1 running live (for obvious reasons), but can set up another
> instance to try and replicate it, or even disable our temporary fix and send
> through some logs from "in the wild"....

Could you confirm you are running 3.18 or 3.20 without any other changes?
It would be great to have a test instance to see what happens.
Comment 5 Jonathan Druart 2015-07-15 07:16:51 UTC
On http://library.pbc.wa.edu.au/cgi-bin/koha/opac-search.pl: "using Koha 3.14.1", is it correct?
Comment 6 Jonathan Druart 2015-07-15 07:17:37 UTC
Ok seems to be 3.20.00
<meta name="generator" content="Koha 3.2000000" />
Comment 7 Nicholas van Oudtshoorn 2015-07-16 01:10:12 UTC
(In reply to Jonathan Druart from comment #5)
> On http://library.pbc.wa.edu.au/cgi-bin/koha/opac-search.pl: "using Koha
> 3.14.1", is it correct?
No! That needs fixing - thanks for pointing it out! :-)
We're running a pretty stock install; the only big change we've made is to implement bug 10988 (Google OAuth2 logins for our students).

I'm not in at that job until next week again. I'll see about getting some more details or a test instance or something up then.
Comment 8 Katrin Fischer 2015-07-19 21:59:47 UTC
I also tested this on master - works ok for me. All pages in cataloguing search seem to display results as expected.

Jonathan, could this be a problem with one of the filters again?
Comment 9 Jonathan Druart 2015-08-04 06:47:04 UTC
(In reply to Katrin Fischer from comment #8)
> I also tested this on master - works ok for me. All pages in cataloguing
> search seem to display results as expected.
> 
> Jonathan, could this be a problem with one of the filters again?

Yes, it could be.
Comment 10 Jonathan Druart 2016-04-04 15:16:20 UTC
Nicholas, could you confirm it is fixed?
Comment 11 Nicholas van Oudtshoorn 2016-04-07 01:53:39 UTC
I'm away from Koha for the next week or so, but will put it on the list to do!
Comment 12 Nicholas van Oudtshoorn 2016-04-12 04:57:09 UTC
Hmmm - it seems to be working. I'll recheck once I update to the May release - but for now it seems to be fixed.
Comment 13 Nicholas van Oudtshoorn 2016-06-02 06:11:15 UTC
Created attachment 51959 [details] [review]
Attempt to fix

Hmmmm - got the same problem happening with the system upgraded to 16.05.
If I search for something such as "worship", I get the first page. But the pager creates links of the form:

https://library.pbc.wa.edu.au/cgi-bin/koha/opac-search.pl?q=worship%20%23relevance_asc&offset=20&sort_by=relevance_asc

Clicking on such a link brings up a "No results found" page.

Modifying this link to be of the form:

https://library.pbc.wa.edu.au/cgi-bin/koha/opac-search.pl?q=worship&offset=20&sort_by=relevance_asc

that is, removing the %20%23relevance_asc , allows the search to work.

This also happens on Intranet searches.
The attached fix seems to fix it, but I'm pretty sure it's just tidying over a problem elsewhere...

Note: our site is currently live with this fix applied. But you can see the old behaviour by clicking on the first link above!
Comment 14 Jonathan Druart 2016-06-11 15:28:52 UTC
(In reply to Nicholas van Oudtshoorn from comment #13)
> Note: our site is currently live with this fix applied. But you can see the
> old behaviour by clicking on the first link above!

Which one? https://library.pbc.wa.edu.au/cgi-bin/koha/opac-search.pl?idx=&q=worship then click on second page, it works.
Comment 15 Nicholas van Oudtshoorn 2016-06-11 15:38:34 UTC
Hmmmm.... I think my patch might be masking the problem (needed a quick fix!) I'll see about rolling a version without the patch this Thursday when I'm back in at that job 😃
Comment 16 Nicholas van Oudtshoorn 2016-06-16 02:35:21 UTC
I've set up a test-opac, accessible here:
http://library.pbc.wa.edu.au:8765/

This test opac is identical with the main opac ( https://library.pbc.wa.eud.au ), except for:
1. It isn't on HTTPS :-)
2. I have taken out the quick fix applied to the main opac to make things work.
In other words, the test-opac at library.pbc.wa.edu.au:8765 hasn't been modified to hide this problem.
Both the test opac (port 8765) and the normal one point to the same data.

To see the problem, try searching on both the main and test opac. For example, searching for worship:
MAIN OPAC: https://library.pbc.wa.edu.au/cgi-bin/koha/opac-search.pl?idx=&q=worship
TEST OPAC: http://library.pbc.wa.edu.au:8765/cgi-bin/koha/opac-search.pl?idx=&q=worship

Then, try and use the pager. For me, the main opac (with the patch above applied) works, but the test opac (unpatched) doesn't. 

Also, not sure why the breadcrumb reads:

Results of search for 'worship _asc #relevance_asc' 

When it should just read:

 Results of search for 'worship'
Comment 17 Jonathan Druart 2016-06-21 12:27:12 UTC
Using my dev install, without local modification, I get:

   Results of search for 'kw,wrdl: d' 
when you get
    Results of search for 'd #relevance_asc'

Do you have local modifications? Do you have stuffs in OPACUserJS? Do you use QueryParser (pref UseQueryParser)?
Comment 18 Jonathan Druart 2016-06-21 12:28:07 UTC
Ok, I reproduce with UseQueryParser turned on.
Comment 19 Tomás Cohen Arazi 2018-02-01 13:43:16 UTC
(In reply to Jonathan Druart from comment #18)
> Ok, I reproduce with UseQueryParser turned on.

The built query is incorrect.
Comment 20 Katrin Fischer 2020-02-24 20:50:58 UTC
We've voted to remove the QueryParser code (https://wiki.koha-community.org/wiki/Development_IRC_meeting_4_March_2020), so I am closing this WONTFIX.