Last modified: 2014-10-08 17:29:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 19938 - last search results page contains next page link if result count is multiple of limit
last search results page contains next page link if result count is multiple ...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Search (Other open bugs)
1.21.x
All All
: Normal minor with 1 vote (vote)
: ---
Assigned To: Dylan Lexie
http://en.wikipedia.org/w/index.php?t...
: easy
: 30163 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-26 07:56 UTC by Felix Pahl
Modified: 2014-10-08 17:29 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Felix Pahl 2009-07-26 07:56:21 UTC
If the number of search results is an integer multiple of the number of results displayed on one page (e.g., a search for "portend" in the English Wikipedia currently yields 200 results, a multiple of 20, 50 and 100), the last page of results contains a link to the next page of results; clicking on this leads to a page that says "There were no results matching the query". (By contrast, if the number of results isn't a multiple of the number per page, the last, partial page still has the text for the next page link, but it's not a link.) 

P.S.: I selected version "1.16-svn" because that was the closest to 'wgVersion = "1.16alpha-wmf"' specified in the HTML source of the search results page. Since this is probably the only way for a lot of people to find out which version they're reporting about, the versions running on the major Wikipedias should preferably be options in the version list (or it should be more obvious which version to choose based on that information).
Comment 1 Brion Vibber 2009-07-27 17:18:12 UTC
Assigning to Trevor -- search UI fixups.

(Note this should be easier to test locally now if you enable $wgSearchMySQLTotalHits (or fudge the #s in the class temporarily)
Comment 2 Roan Kattouw 2009-07-27 21:45:19 UTC
Should probably just pull $limit+1 results and only show the (next) link if the $limit+1'th result is actually there.
Comment 3 Valerie Juarez 2013-01-02 21:26:54 UTC
This issue still persists. 

There are 11,750 articles containing the word "hunger". This is divisible by 50 and 250. 

This is the last page of results - 
http://en.wikipedia.org/w/index.php?title=Special:Search&limit=250&offset=11500&redirs=1&profile=default&search=hunger

If you scroll all the way down that page and select "next 250", the next page has the message "There were no results matching the query."
Comment 4 Sumana Harihareswara 2013-02-21 23:49:02 UTC
I predict that this is relatively easy to fix.
Comment 5 Valerie Juarez 2013-02-22 17:14:34 UTC
Going to assign to 'Nobody'. Having this already assigned to Trevor may deter someone from taking this bug.
Comment 6 Dylan Lexie 2013-03-18 02:01:47 UTC
gerrit Ic30586e217fbde4b9d0aeda277a77030c4dce216
https://gerrit.wikimedia.org/r/#/c/54317/
Essentially follows Roan Kattouw's suggestion.
(Sorry about the long lines in the commit message. This is my first experience with Gerrit and I didn't anticipate a non-wrapping display.)
Comment 7 Gaurav Chawla 2013-04-20 12:07:03 UTC
Your patch seems to be correct. Don't know why, the bug is still showing 'NEW'.
But, since its open, I would like to give an alternate solution.

In SpecialSearch.php,
replace 
   "max( $titleMatchesNum, $textMatchesNum ) < $this->limit" 
by
   "max( $titleMatchesNum, $textMatchesNum ) < $this->limit || $totalRes == $this->limit + $this->offset"
Comment 8 Alex Monk 2013-04-20 16:09:27 UTC
(In reply to comment #7)
> Your patch seems to be correct. Don't know why, the bug is still showing
> 'NEW'.

Assigned to Dylan Lexie. New accounts don't have the ability to modify bug statuses like that.
Comment 9 Andre Klapper 2013-05-02 12:56:04 UTC
*** Bug 30163 has been marked as a duplicate of this bug. ***
Comment 10 Gerrit Notification Bot 2013-11-03 08:23:42 UTC
Change 54317 had a related patch set uploaded by Nemo bis:
Fix for Bug 19938 (final page of search results sometimes having erroneous "next" link)

https://gerrit.wikimedia.org/r/54317
Comment 11 Gerrit Notification Bot 2014-06-11 01:17:38 UTC
Change 54317 merged by jenkins-bot:
Final page of search results sometimes having erroneous "next" link

https://gerrit.wikimedia.org/r/54317
Comment 12 Andre Klapper 2014-09-01 12:45:00 UTC
All patches mentioned in this report were merged or abandoned - is there more work left to do here (if yes: please reset the bug report status to NEW or ASSIGNED), or can you close this ticket as RESOLVED FIXED?
Comment 13 Alex Monk 2014-10-08 17:29:53 UTC
Sounds resolved to me. Marking as such.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links