Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem:
We use a block view with exposed filters and ajax. When users go on a content and come back on the page, filters are always fill like they want but the view show content for filters by default and they must click again on the button "Filter". The behavior is the same when we reload the page. So, we want to keep result of the filters previously selected when we comeback or reload the page.
Steps to reproduce:
- Create a view as block (I don't know if this happens with an other type)
- Add exposed filters and activate ajax
- Place the view on a page and used its exposed filters
- Go in a content, then comeback to your page with the previous button of your navigator
- View's filters are always fill but the view show results of the default filters
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | before-using-views-ajax-history.gif | 2.3 MB | flyke |
| #12 | after-using-views-ajax-history.gif | 1.55 MB | flyke |
| #3 | filter_not_after_back.png | 236.76 KB | mile23 |
| #3 | filter_applied.png | 229.86 KB | mile23 |
Comments
Comment #2
moonpeak commentedHey Calystod,
Can you attach screenshots for better understanding w.r.t steps you have mentioned?
Comment #3
mile23Here are some screenshots.
I made a view that shows all nodes, sorted by date. It has an exposed sort based on date, and also an exposed filter for whether the node is published or not.
In this pic, the user has selected 'No' for published and clicked 'Apply'. Views then uses AJAX to update the list of items shown. You see that 'Similis' is pink, showing that it's unpublished.
The user visits the content (in this case 'Similis'), and then clicks the back button on their browser.
When they go back, the user is shown the view without the filter applied, even though the published filter dropdown still has 'No' selected. 'Dignissium Quae Valde' is a published article.
The original poster wants the view to be updated when the user goes back, so that it reflects the displayed filter elements that remain as they were when the user left them.
*I* want the opposite: That when you go back, the exposed filter form elements are all back to the way they were when you first visited the page, and not the way they were set when you left it.
Either way, the page should re-trigger an AJAX query which then reflects the exposed filters and sorts.
Filters have a 'remember last selection' option, which does not change anything in this scenario, since the view results are the same as when we first visited the page, which might not reflect the visible state of the filter form elements.
Comment #6
pameeela commentedThanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.
As part of the Bug Smash Initiative, we are triaging Drupal core issues with the priority 'Major'.
It looks like this is a duplicate of #1248332 so I'm going to mark it closed, but will update the other ticket to reference this one and assign credit for contributors here.
Comment #7
berdirI believe this is not a duplicate unless that other issue would to more than the title says.
This also happens when you don't use the remember feature. A non-ajax view has URL query arguments that update when you change the filters, so you have a working browser history. Ajax doesn't do that. I actually just implemented a feature that uses JS to update the URL/history based on the selection this week for a client project, but it has limits, like only working for a single view per page and I've hit other ugly bugs like #3160406: Exposed forms with checkboxes don't work correctly if the checkbox value is in the URL in the process.
Comment #8
longwaveI think this might be more a duplicate of #2610434: AJAXified Views should also change the URL by using history.pushState()?
Comment #9
berdirHa.
Quoting myself from Slack today:
> every views ajax related issue has at least 3 related and overlapping issues
Proven true again.
Agreed, that's a better duplicate candidate.
Comment #10
pameeela commentedThis is exactly what I was thinking... would be great to collate them into a meta that outlines them all and could be an easy reference for duplicates!
Comment #11
pameeela commentedComment #12
flyke commentedI just want to inform people that installing, enabling and configuring the views_ajax_history module fixed this for me.