[2012-07-10] Retain pages list view state (pagination, filters) when returning from detail view

silverstripe-issues commented 11 years ago

created by: @chillu (ischommer) created at: 2012-07-10 original ticket: http://open.silverstripe.org/ticket/7642

Followup from http://open.silverstripe.org/ticket/7589

The pages list view loses its state when navigating into a page detail view, and then going back via browser back button. This is due to the information being stored in GridState in the PHP session, associated to the field by a unique ID.

Same problem for ModelAdmin (originally described in http://open.silverstripe.org/ticket/7416 )

There's four different ways we can persist this information. None of them are great. @Hamish/Stig: Could use some feedback here :)

== Cookies ==

Any state is view specific, so at the least tied to the URL. This pretty much disqualifies cookie storage, since we'd need to keep too much information. To illustrate this, if you edit 50 pages in the course of a session (each with a GridField), you'd have around a 1000 key/value pairs from GridFields.

== URL GET parameter or HTML5 history state ==

URL storage is not as easy as it sounds: The HTML5 History API forces us to reload a URL via ajax unconditionally. Take a pagination request for GridField (paraphrased) POST admin/pages/edit/show/2/field/MyGridField State=&action=next_page This loads the table only, and advances the current page in the PHP session. If we push this to the history stack, and a user navigates back to this page later on, it should load the full CMS view instead of the field, and not advance the current page. There's history.replaceState(), but it still triggers a reload with the same problems. Same goes for pushing to the history state object, rather than URL GET parameters.

== HTML5 sessionStorage ==

HTML5 sessionStorage is a more heavy duty replacement for cookies, so still clientside. So we'd need to wait for the GridField to render, then look up its state ID, and request the view with this stored state. Not ideal.

== PHP session ==

Still would need to be keyed to the currently viewed URL, but we can initiate the GridField with the current state automatically without a refresh. This is not the cleanest solution, but most attractive in terms of loading performance.

I think the URL is where this information belongs. Putting that information into the URL and into the history, would also allow to keep track of the last displayed tab. Currently, if you move away from a page and come back with the browser's back button, the tab state is lost along with everything else.

Maybe we can find a way to avoid having to reload every time. For things like filtering and sorting it might still be necessary (since applying a filter to a paginated field might show items from pages that have not been loaded yet), but for tabs it would be a pain.

silverstripe-issues commented 11 years ago

comment by: @chillu (ischommer) created at: 2012-07-13

Fixed http://open.silverstripe.org/ticket/7647 by using HTML5 sessionStorage, but only for tab state.

silverstripe-issues commented 11 years ago

comment by: camfindlay created at: 2013-02-27

I have a new use case which bring up the same issue in 3.0.5 for modeladmin.

If you open a modeladmin and:

1) run a filter 2) seleclt an item to edit 3) edit this item then save and publish 4) click the back button 5) you end up back at the initial modeladmin screen and it loses the filter search from the url.

This workflow on a project at the moment has made a lot of extra work for a client that does a lot of sub editing.

HARVS1789UK commented 10 years ago

Has any solution to the last point been found yet? I have the same issue described above when filtering in ModelAdmin AND saving the record in the DetailForm (if you don't save the back button and breadcrumbs behave as expected and keep memory of the filter options).

I also have a similar issue with GridField pagination i.e:

1) Go to GridField results page 2 of 3 2) Edit a record (opening the DetailForm) 3) Click 'Back' link or breadcrumb link (regardless of whether you have saved this record or not)

This results in you being returned to GridField results page 1 of 3 instead of page 2 where you were.

I am working on a fix for the first issue (though I don't think its very professional and is a bit of a hack) but don't know where to start with the second. Does anyone have any solutions?

Kind regards,

HARVS1789UK

sminnee commented 7 years ago

Confirmed still a problem in ss4

xini commented 7 years ago

Any chance this gets looked at some time soon?

chillu commented 7 years ago

I doubt we'll get around to this before moving GridField into a React component, where that behaviour will be easier to attain (more state managed on the client). If you want to have a crack at it, start with GridFieldEditButton->getColumnContent() which renders the link. Form submissions will make this a bit tricky, you might need to implement BackURL there.

xini commented 7 years ago

Thanks, @chillu.

GuySartorelli commented 1 year ago

This was resolved in https://github.com/silverstripe/silverstripe-admin/issues/1314

silverstripe / silverstripe-cms

[2012-07-10] Retain pages list view state (pagination, filters) when returning from detail view #503

Related