Gridfield Better Buttons don't handle sorting and pagination

[maxime-rainville]

Our better button implementation in core seems to have some issues.

• When using the next button, you can't seem to go more than 2 entries past the current page
• When sorting the gridfield, the next/previous button don't respect your sort order.

https://youtu.be/Mg8sptRZKc8

Parent issue:

• https://github.com/silverstripeltd/product-issues/issues/254

Pull request

• BUG Do not override grid state with search parameters #1103
• Make the previous and next buttons always work silverstripe-framework#9827
• Add pagination tests for grid fields to make sure next and previous buttons work #1238

[roopamjain01]

I am also getting the issue with previous and next button, please find the issue detail below.

My Silverstripe version is 4.4 and grid field next and previous button functionality working randomly.

I have grid with 25 records. I have two pages in my grid, means item per page is 15 in the grid.

When I click on first record on the first page in the grid, I can press next button till the 16th record and then next button is disabled on the 17th record.

But when I start from second page in the gird from 18th number record then next record should be the 19th number record but currently after 18th record I am getting 2nd number record as a next record and after that I can see next button till the 16th record and on the 17th record again next button is disabled.

In my case I expect next button should work for all the 25 records in the grid and next button should be disabled on the 25th record. But next button disabled after 17th records according to the current code in GridFieldDetailForm_ItemRequest.php at line 540($limit = $itemsPerPage + 2).

In second senario, when I click on the 15th number of record on the page 1, I can see next button only for 15th and 16th record and then again next button is disabled on the 17th record, but I think I should be able to see all the record from 15th to 25th (all 10 recods) and next button should be enabled.

Same issue with previous button as well, when I click on the 25th number record on page 2, I can see previous button till 16th record and then previous button is disabled on 15th record on page 1. But I expect previous button should work till first record in the grid.

Please let me know If you need any other information.

[bergice]

The pagination will either be incorrect or missing in \SilverStripe\Forms\GridField\GridFieldDetailForm_ItemRequest::getAdjacentRecordID, meaning that the resulting list will be filtered to the wrong section which is why the previous/next buttons will be disabled.

Ideally we should not depend on the pagination offset and items per page as it's possible to open a record by URL without passing the query string to the detail form.

So we'd need to find the index of the current record and then offset from there somehow.

[maxime-rainville]

We think it's worth spending about 3 story points getting the existing PR across the line.

If it turns out to be more difficult than that, then we should focus on addressing this issue through https://github.com/silverstripeltd/product-issues/issues/254

[emteknetnz]

I've spent some time debugging how the existing implementation works and why selecting the bottom record on the first page of results will only allows you to get 2 more next records.

I have not investigated the prev button on the third page of results. I have not investigated records being returned in the wrong order.

$list = $gridField->getManipulatedList(); will return 15 records, respecting the sorting and filtering.

        $limit = $itemsPerPage + 2;
        $limitOffset = max(0, $itemsPerPage * ($currentPage-1) -1);

        $map = $list->limit($limit, $limitOffset)->column('ID');

Will then re-query the database (I think), respecting sorting and filtering, and get an additional 2 records (15 $itemsPerPage + 2 = 17) with an offset of 0

You can click the next record button 2 times. The issue is that $list = $gridField->getManipulatedList(); is still bound to the first page of results, even though you've navigated past that. Sure you could increase this limit from 2 to something higher to allow more clicks, but it just means you can click more times before it stops working. It's a bandaid solution. It also won't solve the incorrect sort issue also identified.

You cannot simply query by record ID, because this doesn't respect sorting or filtering

An easy way to solve this would be to re-query the entire database table without a LIMIT or OFFSET, however this is likely to be problematic if you have a gridfield on a database with a 100K records which while it is a lot and you could question if a gridfield is appropriate, CMS users may find handy to do searching/filtering on. It doesn't seems like a good solution just to get a next/prev button.

I'm not sure if this is possible, though it seems like solution here would be do another query that includes respect sorting and filtering, and somehow has an OFFSET ($limitOffset) of the current record -1 and a LIMIT of 3. I not overly familiar with the inner workings of gridfield, so don't if it's possible calculate the correct OFFSET value without returning the entire database table.

Would this work if you navigated to URL of the item edit form directly without first visiting the gridfield?

Given this implementation is currently broken, unless someone is a able to identify a robust solution I'm inclined to remove the next/prev buttons from the edit forms

[bergice]

@emteknetnz I've just tested this and it looks like the sorting is indeed still broken with the new approach.

However, filtering still works:

SELECT DISTINCT "Product"."ClassName", "Product"."LastEdited", "Product"."Created", "Product"."Version", "Product"."Item", "Product"."Type", "Product"."Notes", "Product"."Quantity", "Product"."Description", "Product"."ImageID", "Product"."PriceCurrency", "Product"."PriceAmount", "Product"."ID", 
			CASE WHEN "Product"."ClassName" IS NOT NULL THEN "Product"."ClassName"
			ELSE 'Product' END AS "RecordClassName"
 FROM "Product"
 WHERE ("Product"."Item" LIKE ?)
 AND ("Product"."Type" LIKE ?)
 AND ("Product"."ID" <= ?)
 ORDER BY "Product"."ID" DESC
 LIMIT 30

Not sure how much work would be involved in getting this working properly, but I'll park it for now.

[GuySartorelli]

Closed in favour of #1315