Allow pagination of element lists that exceed QA_MAX_LIMIT_START #932
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The main issue is that
QA_MAX_LIMIT_START
is limiting the amount of pages displayed when using the Q2A pagination. This is fine for most core features, but when writing plugins, it might be important to override this limitation. Of course it is possible to copy/paste the function and tweak it, but that's just not great.Instead of adding another parameter to the huge function, I thought that one parameter could be re-purposed. The
$hasmore
parameter is there to add an ellipsis at the end of the pages. At first sight, it seems related to the limit imposed byQA_MAX_LIMIT_START
: if the limit is reached and there are more results that are not being displayed, at least show the ellipsis to tell the user there are more stuff.However, that is not correct. If it was, then why send it as a parameter? At the end of the day, the function on its own should be able to tell if the limit has been exceeded or not based on the
$count
parameter. Well, it seems the issue relies in search modules.Search modules don't return the amount of total results that were matched with the search. They just return the specific slice of the results. This is fine to improve performance... but how can we tell the total amount of pages to build the links then? The approach is just fetching a few more results and add some additional pages. So when building the links, the core can certainly tell if there are a few more pages but can't tell if there are more. So in this case, the
$count
parameter is not really a count and the fix for that is to override the ellipsis from outside the function, using the$hasmore
parameter.So we can replace the
$hasmore
with a custom limit, which would default toQA_MAX_LIMIT_START
for backwards compatibility and, if set explicitly to boolean by plugins, it can be converted to integer inside the function. Then, the function will figure out if the ellipsis is needed or not. For the specific case of the search module, we can apply this logic: if we got less records than we requested then we know we are at the end of the list so avoid the ellipsis, otherwise, add the ellipsis.Sorry for the long explanation, but it took me a while to understand why things were the way they were.