Page MenuHomePhabricator

last search results page contains next page link if result count is multiple of limit
Closed, ResolvedPublic


Author: fpahl

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).

Version: 1.21.x
Severity: minor
See Also:



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:44 PM
bzimport set Reference to bz19938.
brion added a comment.Jul 27 2009, 5:18 PM

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)

Should probably just pull $limit+1 results and only show the (next) link if the $limit+1'th result is actually there.

Valerie.m.juarez wrote:

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 -

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."

sumanah wrote:

I predict that this is relatively easy to fix.

Valerie.m.juarez wrote:

Going to assign to 'Nobody'. Having this already assigned to Trevor may deter someone from taking this bug.

dilexie wrote:

gerrit Ic30586e217fbde4b9d0aeda277a77030c4dce216
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.)

grviitr wrote:

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,

"max( $titleMatchesNum, $textMatchesNum ) < $this->limit"


"max( $titleMatchesNum, $textMatchesNum ) < $this->limit || $totalRes == $this->limit + $this->offset"

(In reply to comment #7)

Your patch seems to be correct. Don't know why, the bug is still showing

Assigned to Dylan Lexie. New accounts don't have the ability to modify bug statuses like that.

  • Bug 30163 has been marked as a duplicate of this bug. ***

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)

Change 54317 merged by jenkins-bot:
Final page of search results sometimes having erroneous "next" link

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?

Sounds resolved to me. Marking as such.