TYPO3 Core

The issue is even worst. If you go on the third page of the list (implying you have a third page), take a look what range the indicated previous page suppose to have:

<- [1 - 200] ... [201 - 300] ->

The entire list here is in the '...', previous-page range is the entire previous range, not just the one of the page, the next-range is allright.

I have a paging-range of 100.

Additionally there is some strange behaviour aspect in that switching from "normal-table-view with X entries" to "exclusive table-view with Y entries":

1. normal view, first page: [21 - 212] >
2. click next page: < [1 - 20] ... [121 - 212] ->

This is not true! The previous page is not entry 1-20, but 1-100.
This appears somehow like nitpicking, but I have the impression the entire paging/list system is severely and basically flawed, showing that much strange and inconsistant artifacts.

I don't even dare to try to create a functional patch, I doubt anybody will accept the hacks I'd to provide, considering that this a a heart-piece of TYPO3, and I'm not the authority for db_list (as seen by the patch which in it's simplicity doesn't fix the reported bug).

Niels, your latest comment is solved with a new pagination concept in #17225. A patch is currently pending in core list, please test.

Your current patch still has a flaw when sorting items, quote from my review in the core list:

Moving first element of second page up fails with your patch, tested
with tt_content and tx_comments_comment records. I receive two error
messages:

1: Attempt to insert a record on page '' (1668) from table 'tt_content'
without permissions. Or non-existing page.

1: Attempt to move record '101' (tt_content:1666) without having
permissions to insert.

In this case tt_content:1666 is the record I am trying to move up, and
1668 is the second last record on the previous page (this means 1666
should be sorted as next record after 1668).

From the error message it seems the system tries to insert the record 
on page 1668.

Added Steffens screen shot to illustrate this issue.

I redid this patch and came up with a new version that doesn't need additional db queries.

Please test and give feedback in core list.

fixed in 4.2.6 and 4.3 alpha 2