Summary: | Using QueryParser: Cataloging searches with more than 1 page results show blank pages after page 1 | ||
---|---|---|---|
Product: | Koha | Reporter: | Chris Cormack <chris> |
Component: | Cataloging | Assignee: | Galen Charlton <gmcharlt> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | major | ||
Priority: | P3 | CC: | jonathan.druart, tomascohen, vanoudt |
Version: | Main | ||
Hardware: | PC | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Bug Depends on: | |||
Bug Blocks: | 12742 | ||
Attachments: | Attempt to fix |
Description
Chris Cormack
2010-05-21 00:51:00 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... Nicholas, This sounds really bad. I don't reproduce the error, could you please give us more details? 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".... (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. On http://library.pbc.wa.edu.au/cgi-bin/koha/opac-search.pl: "using Koha 3.14.1", is it correct? Ok seems to be 3.20.00 <meta name="generator" content="Koha 3.2000000" /> (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. 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? (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. Nicholas, could you confirm it is fixed? I'm away from Koha for the next week or so, but will put it on the list to do! Hmmm - it seems to be working. I'll recheck once I update to the May release - but for now it seems to be fixed. 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! (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. 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 [U+1F603] 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' 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)? Ok, I reproduce with UseQueryParser turned on. (In reply to Jonathan Druart from comment #18) > Ok, I reproduce with UseQueryParser turned on. The built query is incorrect. 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. |