jQuery tablesorter pager at the bottom does not show initially

• Bug

jQuery tablesorter allows to control the maximum number of rows to display in a table. When the number of data records exceeds that maximum, the pager widget or the pager plugin paginates the data on multiple pages. tablesorter, for example on tiki-listpages.php, therefore displays a pager area which at the top of each table. This area provides controls to change the maximum number of rows in a page and to select the page to display, as can be seen in the attached screenshot.

This area can not only display at the top of tables, but also at the bottom, so that when one scrolls through a dataset from start to finish, there is no need to go back to the top to continue to the next page. There is however an optimization so that the pager does not display twice at the same time in the viewport. lib/core/Table/Code/Bind.php line 33-39 (in Tiki 18) either show or hide the bottom pager:

if (this.config.pager.endRow - this.config.pager.startRow > 15) {
			$('div#listpages1-pager.ts-pager-bottom').css('display', 'block');
		} else {
			$('div#listpages1-pager.ts-pager-bottom').css('display', 'none');
		}

This is based on a rule of thumb which estimates that a viewport fits 15 rows. When browsing 70 records and viewing records 1 to 25, endRow has the value 25 and startRow has the value 0, so the difference between the 2 is 25, which is more than 15. Therefore, the bottom pager's div is displayed.

This code is run whenever the pager is used, plus at page load. The code works fine once the page has finished loading, but on page load, it is unfortunately fragile. When this code is first run, endRow has the value 0, so the difference is always 0 and display is always set to none. The initial display is fine in Tiki 15 up to 17 because this code (which runs when the tablesorter-ready event occurs) runs several times during page load, and endRow has the correct value the last time the code runs. In Tiki 18 the code only runs once per page load. This would be a good thing for performance, except that this one run is unfortunately too early, so the difference is always 0.

As I verified Tiki's related code seems unchanged between Tiki 17 and 18, I imagine this regression comes from the upgrade of jQuery tablesorter from 2.28.5 to 2.31.1. This persists in Tiki 19, and in trunk as of r70207.

This bug has been demonstrated on show2.tiki.org

Please demonstrate your bug on show2.tiki.org

This bug has been demonstrated on show.tikiwiki.org

Please demonstrate your bug on show.tikiwiki.org