Respect settings.queryLimit when pagination is activated, too

[merzilla]

When pagination is enabled (in listView), and a value is set in settings.queryLimit also, the queryLimit is not used correctly.

So e.g. if I set settings.pagination.itemsPerPage = 6 and settings.queryLimit = 3 I get 6 results, but at least no more pagination links.
The expected result should be to have 3 records.

I could provide a PR, @derhansen , that takes care of settings.queryLimit in the getPagination() of AbstractController, if its value is > 0.

So basically instead of
$paginator = new QueryResultPaginator($events, $currentPage, (int)($settings['itemsPerPage'] ?? 10));
it should be
$paginator = new QueryResultPaginator($events, $currentPage, (int)($this->settings['queryLimit] ?? 10));
i guess, and it should be fine.

What do you think? Should I create the PR?

[derhansen]

This is actually a flaw in the TYPO3 core paginator, which has never been tackled. Opinions on, how the core pagination should handle this, are discussed in those gerrit patches:

• https://review.typo3.org/c/Packages/TYPO3.CMS/+/72817
• https://review.typo3.org/c/Packages/TYPO3.CMS/+/80326

Your suggested change does however not fix the behavior and will lead to, that itemsPerPage is not respected any more. And the problem is sadly not so easy to fix.

See also the discussion in ext:news issue tracker regarding the problem and which scenarios need to be respected.

Finally, ext:news solved this by extending TYPO3\CMS\Core\Pagination\AbstractPaginator. (see https://github.com/georgringer/news/blob/main/Classes/Pagination/QueryResultPaginator.php).

So the solution would be to adapt the custom ext:news Paginator to the extension. This will however take some time, as I would like to implement the solution with full test coverage for v7 and v8 of ext:sf_event_mgt.

If you need a workaround for your usecase, I suggest to disable pagination in the plugin, if it also defines a queryLimit which is less than itemsPerPage.

[merzilla]

Thanks for your reply @derhansen :)
Ok, I see.. it is more complicated then I thought. I mean with my change, I wanted to surround it with some condition to check if queryLimit is set and > or < than itemsPerPage etc.

Your suggestion also sounds good, but I think a custom TCA condition would be needed. E.g. imagine that pagination is active, and then an editor enters a queryLimit. A custom code needs to do the displayCond stuff and in background disable pagination then depending on the case.

I'll let you know about what the stakeholders think about it.