Persist GridField state between requests

[MarcusDalgren]

As far as I can see right now everything for the GridField is handled via POST requests which means that whatever you've done with the GridField (paginated, sorted, searched etc) is lost if the page is reloaded.

A pretty common usecase where this becomes really annoying is when you have to do some kind of repetetive task with a number of records. Right now you search/filter/paginate for them, click one, edit & save. When that's done and you press back the GridField is reset and you have to do the search/filter/paginate thing all over again.

If this is accepted as an issue I'd be willing to tackle it with the caveat that I've no idea how to do this properly in the current context. Can we switch to get variables for search/filter/paginate? Should we store it in session (feels bad)?

[wilr]

AFAIK State has some session backing. See GridState and https://github.com/silverstripe/silverstripe-framework/blob/3.1/forms/gridfield/GridField.php#L836

[kinglozzer]

Partly related: #3542

[sminnee]

Putting everything into get variables is the "cleanest" when it comes to supporting multiple browser tabs, etc, although the get variable namespace can get cluttered and you can sometimes hit max-url-length issues.

Perhaps immutable GridState can be stored in the session, so that you have a ?GridStateID=<ID> on the relevant URLs, but then when the grid state changes, a new ID is set. That way, using functions like open-in-new-tab wouldn't break things.

The session storage of that GridState would get cluttered, so maybe we would need some kind of garbage collection facility: a session could store a maximum of 100 GridStates, and the least recently accessed ones would be deleted.

Alternatively, GridState could be packed into a JSON blob and saved as a single get variable. That would minimise namespace pollution, but might hit URL-length issues. For smaller quantities of GridState, it might be okay.

Regardless, the number of different potential solutions here suggests that it would be good for GridField state management to be pluggable.

[g4b0]

I think that Immutable GridState + Garbage Collector should be the right way to handle this issue.

[g4b0]

Any news? It's a quite annoying issue when managing big GridField.

[purplespider]

I've just posted a $50 bounty for this: https://www.bountysource.com/issues/2778676-persist-gridfield-state-between-requests

I've recently launched a site that has a booking system on it, a ModelAdmin displays 1 record per date for the next 2 years, allowing the admin to change the availability status for each date. With over 700 records, it's very annoying that when clicking Save & Close or Back from an EditForm, that it drops you back at the top of page 1 of the GridField.

Can I just add, that as well as remembering which page you were on, it should also remember the position on that page, or at least scroll down the page to the position of the record that was just edited. For some things I find it's better to scroll down a long page of records than have to paginate through multiple pages.

[gavro]

Tried getting some useful statelogic in gridviews with a JS only approach. See:

• Persist the filter for model admins, and pages list view #3542 (comment)
• https://github.com/novatio/silverstripe-statefulgridfield

Perhaps this approach might work for you?

[tractorcow]

Alternatively, GridState could be packed into a JSON blob and saved as a single get variable. That would minimise namespace pollution, but might hit URL-length issues. For smaller quantities of GridState, it might be okay.

The problem is that gridstate can be massive, with multiple potential keys per row.
We'd need to segment gridstate into state which can persist via querystring and which via session. It's too large for the querystring to hold.

You would also need to solve the problem of having these querystring args on the top level page, not simply on gridfield postback handlers, as is current.

[3Dgoo]

I have a client who noticed this problem. In the end I added the following JavaScript to the CMS to add the query string to the form action:

(function($) {
    $.entwine('ss', function($) {
        $('.ss-gridfield').entwine({
            onmatch: function() {
                var queryString = window.location.search;
                if (queryString) {
                    if (queryString.indexOf('&action_search') > 0) {
                        queryString = queryString.substring(0, queryString.indexOf('&action_search'));
                    }
                    $('#Form_ItemEditForm').each(function() {
                        var action = $(this).attr('action');
                        if (action) {
                            if (action.indexOf('?') < 0) {
                                $(this).attr('action', action + queryString);
                            }
                        }
                    });
                }
            }
        });
    });
})(jQuery);

For me this fixes it that when save is pressed the back, previous and next buttons all still contain the previous filter.

Hopefully this is useful.

[chillu]

Note that the "current page" state of GridFields in SiteTree->getCMSFields() has been fixed in 3.6 through silverstripe/silverstripe-cms@487235f

[chillu]

@steve-silverstripe has created another fix for this with https://github.com/littlegiant/silverstripe-persistentgridfield as well.

[sabina-talipova]

Solved by silverstripe/silverstripe-admin#1314