Problem/Motivation

Now that #343535: Enable bookmarking of AJAX views has been committed, is this module still needed?

Steps to reproduce

Proposed resolution

Clarify if the module is still needed for some features.
And maybe add an upgrade path to switch to the core implementation.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

prudloff created an issue.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

It is worth nothing that the core functionality and this module have a few fairly important differences, that confused us for quite some time when testing and comparing.

The most important one is that core replaces the current history state, while this module pushes new states. What this means in practice is that with core, you can reload the current filters, you can bookmark the current set of filters, you can click on a linked element and then use browser back. You can however NOT use browser back to go back to a previous filter. I'm not sure what's better.

Also, the core functionality is server side, it determines the URL and filters there, whereas this module I think mostly does it in JS. Both kind of conflict with #2823541: Table clicksort is lost when using views exposed filter & Pager exposed '#items'.

This module is also opt-in per view, while core is not configurable, it just always does it for all views.

We decided to remove views_ajax_history in or projects and stick to the replaceState approach used by core. Both together is pretty weird. If someone would want to use this in 11.3+, I think an event subscriber to remove the core command would be necessary, as documented hiere: #2870341: Change URL in browser with page parameter