The paging in the OPAC search results is now very broken: if you use the next link instead of choosing specific pages, you will be unable to get past page 2, and end up with a query string like this: /cgi-bin/koha/opac-search.pl?q=smith&offset=20&offset=40&offset=40
This is also an issue in 3.8.x.
Problem caused by commit b20ffe15bb365a14fbe20956f038670fe77044ae, Bug 5981 - OPAC: Add limits to search history
Commit is reverted out of 3.8.x now, thanks for the catch
Alex, I'm assigning this bug to you, because you're author of the patch that caused it, see bug 5981. I confirm that the following lines are the origin of the problem: + my $path_info = $cgi->url(-path_info=>1); + $query_cgi = $cgi->url(-query=>1); + $query_cgi =~ s/^$path_info\?//; + $query_cgi =~ s/;/&/g; + $query_desc .= ", $limit_desc"; I've commented them, and the problem described here is gone. Uncommenting them, the problem is back. I can't reproduce Katrin problem described on http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5981#c28, but thi one 8381 is a bug, for sure As your original bugfix contained an updatedatabase, I won't revert it, that would mean creating a "hole" in DB revision numbers, but please fix the problem quickly !
Created attachment 10809 [details] [review] Bug 8381 - Paging broken in OPAC search results Fix also freezing for some browser when performing a search query.
Created attachment 10836 [details] [review] [SIGNED-OFF] Bug 8381 - Paging broken in OPAC search results Fix also freezing for some browser when performing a search query. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Checked paging (previous, next and navigating to page numbers) works. Browser performance is fixed too.
Created attachment 10837 [details] [review] Bug 8381: Fix adding limits to search history for logged in users Due to renaming of some variables the limits were only working for 'anonymous' users. This patch fixes some variables, so limits are also added to history when the user is logged in.
Alex's patch works nicely, but I found a small problem and I would like to see a second sign off on this, because my symptoms were different from what other testers experienced.
Created attachment 10867 [details] [review] [Signed-off] Bug 8381: Fix adding limits to search history for logged in users Due to renaming of some variables the limits were only working for 'anonymous' users. This patch fixes some variables, so limits are also added to history when the user is logged in. Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
(In reply to comment #6) > Created attachment 10836 [details] [review] > [SIGNED-OFF] Bug 8381 - Paging broken in OPAC search results > > Fix also freezing for some browser when performing a search query. what browser?
(In reply to comment #10) > (In reply to comment #6) > > Created attachment 10836 [details] [review] > > [SIGNED-OFF] Bug 8381 - Paging broken in OPAC search results > > > > Fix also freezing for some browser when performing a search query. > > what browser? works fine for me in safari, opera, firefox and chrome passes all QA tests. i'm marking this as 'Passed QA'
I made a lot of tests (logged-in and not logged-in), and could not find anything wrong. chris_c, you can push bug 5981 and this one on 3.8.x branch I think
Either this patch or the patch to bug 5981 has broken the OPAC search in Chrome. With EnableOPACSearchHistory enabled, Chrome crashes on a regular keyword search (q=smith), and hangs on searches using idx=kw&q=smith. Disabling EnableOPACSearchHistory fixes the problem.
Holding off pushing until the problem with chrome is fixed
Jared, is this still a problem in chrome?
(In reply to comment #15) > Jared, is this still a problem in chrome? It doesn't seem to be. I don't have time to do a git bisect, but in between July 17 and now, EnableOPACSearchHistory stopped causing Chrome to hang (this time around Chrome did not crash for me).
I tested searching in Chromium "20.0.1132.47 Ubuntu 12.04 (144678)", with and without EnableOPACSearchHistory, and did not see any problems. Someone with access to Chrome should probably test too, before we close this.
Closing because the bug is no longer reproducible on master.