27

Some searches on stackexchange.com seem to give the wrong number of results. E.g. searching for url:wiki.openttd.org gives 77 results, but they fit on 2 pages of max. 30 results; if you set the page size to 50, they all fit on one page. @rene's analysis is spot on: manually navigating to page 2 gives the other 27. The pagination is broken; it's not related to searching for URLs because searching for 'smokedetector' has pagination problems too.

Improve this question
13
  • Related?
    – Shadow Wizard
    Commented Jan 6, 2021 at 12:03
  • 6
    Other problems with networkwide search: 1. It only displays 15 result per site, although (by default) it says 30. 2. If you try a search which has about 30 results, you do not have access to the next page of results (unless you manually modify the URL). 3. Basically in any search, if you go to the last page, you see only 15n (rather than 30n) results - you can see additional result by changing page=n part of the URL.
    – Martin
    Commented Apr 22, 2022 at 5:32
  • 6
    4. If you switch to 50 results per page, this setting is forgotten when you go to the next page of results. A similar thing was observed here: Does network-wide search for tags work only with is:q? I was considering posting a bug report about this (mainly about the problems described in the previous comment). But all things described there are probably caused by the same problem as the ones described in your question.
    – Martin
    Commented Apr 22, 2022 at 5:35
  • 4
    [status-declined]'ing this one solely based on the likelihood of the team ever getting around to fixing it — it has been sent to their backlog, regardless (but I'm trying to avoid a perma-deferred that is actually a declined).
    – JNat StaffMod
    Commented Feb 23 at 16:36
  • 3
    @JNat time for a [status-permanently-deferred] tag?
    – Glorfindel Mod
    Commented Feb 23 at 17:05
  • 2
    If that site isn't going to be maintained, why keep it online?
    – Kevin B
    Commented Feb 23 at 17:12
  • 13
    @JNat While I understand a status-decline, I disagree with using the tag that way. Most of us understand that there will be things that end up existing in the backlog for extremely long periods of time, perhaps forever. Personally, I'd prefer status-declined to be kept for "we've actively decided not to make changes for this" (because reasons), rather than to indicate that it's still something that's listed internally as potentially being done, but there's just not the resources to do it (unless the internal evaluation is "we're never going to do this unless external changes").
    – Makyen
    Commented Feb 23 at 17:16
  • @JNat what's different here? There are hundreds of bugs and requests in the backlog (i.e. with status review tag) with "likelihood of the team ever getting around to fixing it" around zero. What makes this one special?
    – Shadow Wizard
    Commented Feb 23 at 17:52
  • 4
    @Makyen I think that they're concerned that tagging it as status-deferred will give false hope that it'll soon be implemented, but this is in fact not the case if one reads its full tag wiki.
    – Sonic the Anonymous Hedgehog
    Commented Feb 23 at 19:03
  • 1
    @Makyen: I read this as saying, essentially, "this will not be fixed in at least the next 1-2 years." That is such a long period of time that it is not materially different from saying "this will not be fixed," because no decision is ever truly final anyway.
    – Kevin
    Commented Feb 24 at 1:44
  • 4
    @Kevin To me there is a difference between "won't be fixed" and "won't be fixed right now". Moreover, there are already plenty of proposals in status-review for 2+ years. What makes this one special that waiting 1-2 years is to be considered the same as declined?
    – VLAZ
    Commented Feb 24 at 8:58
  • 3
    @JNat [status-declined] has historically been "we're NEVER doing this because <good reasons>". It was also briefly used for "not on Q1 roadmap" for some reason. Can we avoid redefining it a third time? This can live as [status-deferred] until the heat death of the universe, or until a dev gets bored one Friday afternoon and implements the fix VLAZ has shared below (incidentally, it is licensed under ISC
    – Robotnik
    Commented Feb 25 at 23:11
  • 1
    Very slightly related: Changing how community leadership works on Stack Exchange: a proposal and rough timeline - "community members often feel as though critical product needs go unrecognized or unevaluated; community members often feel as though their opinions on the direction of the Stack Exchange public Q&A product do not matter, are ignored, or are irrelevant.". There is a backlog in an answer.
    – This_is_NOT_a_forum
    Commented Feb 25 at 23:16

1 Answer 1

Reset to default
4

This functionality is crucial in some cases of investigating spam or abuse.

I have therefore created a userscript to correct the functionality. See the Stack Apps post: Fix for the network search pagination

To make sure this post is self-contained:

Installation

Direct install (GitHub)

See the code on GitHub

Code:

// ==UserScript==
// @name            Stack Exchange - fix network search pagination
// @namespace        https://github.com/PurpleMagick/
// @description        Network search pagination is broken and does not count pages correctly. This is a fix
// @author            VLAZ
// @version            1.0.0
//
// @match           https://stackexchange.com/search*
//
// @grant            none
// ==/UserScript==

let __webpack_exports__ = {};

// CONCATENATED MODULE: ./src/paginationParametersHelpers.ts
function retrievePagesize() {
    const searchParams = new URLSearchParams(window.location.search);
    return Number(searchParams.get("pagesize") ?? 15);
}
function createCorrecURL(href, pagesize) {
    const url = new URL(href);
    url.searchParams.set("pagesize", String(pagesize));
    return url;
}

// CONCATENATED MODULE: ./src/index.ts

function main() {
    const perPage = retrievePagesize();
    const searchParams = new URLSearchParams(window.location.search);
    if (searchParams.has("pagesize") === false) {
        window.location.href = createCorrecURL(window.location.href, perPage).href;
        return;
    }
    document.querySelectorAll(".pager a")
        .forEach(el => {
            el.href = createCorrecURL(el.href, perPage).href;
        });
}
main();

If you need to know how to install userscripts, see:

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .