Views - update filters block on ajax request

Created on 28 October 2019, over 4 years ago
Updated 17 January 2024, 5 months ago

When views defines filters in exposed block, and ajax is enabled, ajax requests refresh only view results <div>, exposed filters <div> stays untouched. This is fine, if ajax requests are initialized from exposed filters form submission or pagination. But, when request is initialized from outside exposed filters <div> and exposed filters state changes, exposed filters <div> stays in previous state. Example use case is using views_ajax_history β†’ module. Clicking back button in the browser, will return to previous state of view, but only in view results <div>, exposed filters <div> won't change.

How to reproduce:

  1. Install site with standard configuration.
  2. Install views_ajax_history β†’ module.
  3. Add one article and one page nodes.
  4. For view /admin/content, edit it, set to use ajax and exposed filters as block. Add exposed filter block to /admin/content.
  5. Go to /admin/content and filter Articles
  6. Click back button on the browser. You will see, that view was refreshed (you see again one article and one page), but filter Content type has still Article selected.
πŸ› Bug report
Status

Needs work

Version

11.0 πŸ”₯

Component
ViewsΒ  β†’

Last updated 1 day ago

Created by

πŸ‡΅πŸ‡±Poland gugalamaciek

Live updates comments and jobs are added and updated live.
  • views

    Involves, uses, or integrates with views. In Drupal 8 core, use the β€œVDC” tag instead.

  • Contributed project blocker

    It denotes an issue that prevents porting of a contributed project to the stable version of Drupal due to missing APIs, regressions, and so on.

  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡¦πŸ‡ΊAustralia sime Canberra

    Wondering is it possible to reproduce this with just Drupal Core?

  • πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

    Might be possible to run into this in Drupal core by using the "Exposed form in block" option if anything in that block should be conditionalβ€” at any rate fixing this is necessary for Search API + Facets 3.x to work properly with exposed form in block, where the whole idea of facets is that as you filter inapplicable ones are removed, counts are updated, etc.

    I would bump this to major, personally. It is not only Views AJAX History that is affected.

  • Status changed to Needs review 7 months ago
  • πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

    Oh more important the patch fixes it! So RTBC from the "it works" perspective, needs review from the core code quality perspective.

  • πŸ‡§πŸ‡ͺBelgium borisson_ Mechelen, πŸ‡§πŸ‡ͺ

    I'll add the contrib blocker tag as well for that usecase.

  • Status changed to Needs work 7 months ago
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Will need test coverage to show this issue.

  • πŸ‡§πŸ‡ͺBelgium borisson_ Mechelen, πŸ‡§πŸ‡ͺ

    The problem here is that is hard to reproduce without either facets 3.x or views ajax history. I'm not sure how to add tests for this.

  • πŸ‡ͺπŸ‡ΈSpain akalam

    The patch on #3 is working fine in case there's a single exposed form block. In case there are many instances it will replace only one of them. I'm adding here a modified version using data-drupal-selector instead of the id as selector for the replacement.

  • πŸ‡¨πŸ‡¦Canada liquidcms

    I have facets 3.x and this patch working well to provide a views exposed facet filter (mixed with other exposed filters). It works on our local dev environment as well as Dev server environment. But for some reason i get this ajax error from our staging environment:

    Trying to access array offset on value of type null in /var/www/html/core/modules/views/src/Controller/ViewAjaxController.php on line 214

    the error is from code added by this patch. Checking the html source and there is a [data-drupal-selector={$form['#id']}] attr. Any thoughts on what is causing this?

    A little unclear but it seems like this patch may only be for cases where exposed filters are in a block; but Facets 3.x to combine with other views filters; this is not supported. The filters must be part of the view - not exposed in a block. I"ll test without this patch; although we also have instances on other pages where we do use filters in an exposed block (with ajax).

    Also, not sure what your numbering is for the patch in #16 - it is supposed to use the issue nid: 3090504. What is 13327307?

  • πŸ‡¨πŸ‡¦Canada liquidcms

    Yes, removing this patch and my facets exposed filters (not in a block) combined with other views exposed filters now works correctly on all environments. Of course the places where i use exposed views filters in blocks, no longer work with ajax. PErhaps this patch needs to only apply where needed? I'll take a look at that tomorrow.

  • πŸ‡¨πŸ‡¦Canada liquidcms

    Although i think our solution is no longer needing this patch, i did try to debug what it was doing. I think the method $display_handler->usesExposedFormInBlock() isnt doing what is intended here. I think it is only testing if this is an option; not the value of the option. So even though i don't have my exposed form in a block, this is returning true regardless and the code fails because the next line: $form = $display_handler->viewExposedFormBlocks(); returns null (since i do not have this enabled). This causes my error.

    Also, is the work here not the same as being looked at here: ✨ Exposed forms in a block are not currently updated when Ajax filtering is executed Needs work ?

Production build 0.69.0 2024