Contrib.social

AJAX view with exposed filters & default values does not respect user's empty choice

Open on Drupal.org →
Created on 11 January 2016, over 9 years ago
Updated 29 August 2023, almost 2 years ago

This is the same bug that I reported for the 7.x-3.x version of Views module.

Bug description

On a view with AJAX enabled, and an exposed filter that has default values, if the user chooses to leave the filter's values blank, the view respects user's choise only on the first page of the results, whereas if the user moves to next pages, the result comes back different. This sometimes causes empty pages without pager.

Steps to reproduce

  1. Install Drupal 8.0.3-dev
  2. Create the following Article nodes:
    3. nid title
1   My test article
2   A beautiful day
3   My article is super
4   Master of puppets
5   Fear of the dark
6   This article will fail
7   Awesome article about drupal
  3. Import the view that I paste at the end of that message.
  4. Visit the new view's page: /admin/helper-articles
  5. Type 'article' on exposed filter "title" and DELETE the values from the exposed filter nid (delete both 5 and 10). Click on Apply.

You will see that:

  • You get 3 out of 4 results: nids 3, 6 and 7
  • Exposed filter Title is 'article' as you typed
  • Exposed filter Nid has blank values as you deleted them.

But if you click on the 2nd page on the pager, or the 'next' button', you get an empty view: no results and no pager!
Also you can notice that now the exposed filter 'nid' contains the default values 5 and 10.

More experimenting

To make it more clear, make a small change: Edit the view, and change the pager to 1 item per page.

Visit the view page.
You have 3 results, one on each of the 3 pages.
Now type again 'article' into the title filter, and delete both values on nid. Click Apply.
You get a result of 4 nodes, one on each of the 4 pages.
If you visit page 2 (or 'next'), now you don't get an empty page, because there actually exists a 2nd page, but as you can see, the number of pages is reduced from 4 to 2.

I propose a patch that solves the issue.

The view that was used to test

Please check attached yml file

🐛 Bug report
Status

Needs work

Version

9.5

Component
Views  →

Last updated about 8 hours ago

Created by

🇳🇴Norway efpapado

Live updates comments and jobs are added and updated live.
  • 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.

  • Comment almost 2 years ago →
    🇫🇮Finland tohesi

    Reroll patch from #33 for 10.1.x.

  • Comment 11 months ago →
    🇷🇴Romania cslevy

    Re-rolled patch for 10.3.x

  • Comment 11 months ago →
    🇷🇴Romania cslevy

    Wrong ticket. Sorry

  • Comment 11 months ago →
    🇮🇳India vinmayiswamy

    Hi everyone,

    I’ve tried to reproduce this issue described in the issue description by following the steps mentioned. Here’s a summary of my findings:

    Commit Analysis:
    - The recent commit d251a98 includes a relevant fix in the views/js/base.js file that addresses a similar issue.
    - The updated code now includes logic to handle cases where query parameters might be empty, which aligns with the changes proposed in the patch for this issue.

    Code Comparison:
    Original Patch Diff:

    -      if (pair[0] !== 'q' && pair[1]) {
+      if (pair[0] && pair[0] !== 'q') {

    Recent Commit Diff:

    -      if (pair[0] !== 'q' && pair[1]) {
-        args[decodeURIComponent(pair[0].replace(/\+/g, ' '))] =
-          decodeURIComponent(pair[1].replace(/\+/g, ' '));
+      if (pair[0] !== 'q') {
+        if (pair[1]) {
+          args[decodeURIComponent(pair[0].replace(/\+/g, ' '))] =
+            decodeURIComponent(pair[1].replace(/\+/g, ' '));
+        } else {
+          args[decodeURIComponent(pair[0].replace(/\+/g, ' '))] = '';
+        }

    Findings:
    - The recent commit ensures that query parameters are handled correctly even if their values are empty, resolving the issue of incorrect pagination and filtering behavior.
    - I have tested the functionality in Drupal 11.x, and the filtering and pagination work as expected.

    Given that the recent commit appears to resolve the issue and the functionality works correctly in Drupal 11.x, the patch proposed in this issue may no longer be necessary.

    Request for Feedback:
    - If there are any additional steps or scenarios that I may have overlooked while reproducing the issue, I would be grateful if you could share them with me.
    - I would greatly appreciate any guidance on whether further action is required or if there are any other aspects I should consider.

    Thanks!

  • Comment 5 months ago →
    🇳🇱Netherlands johnv
  • Status changed to Postponed: needs info 5 days ago
  • Comment 5 days ago →
    🇬🇧United Kingdom alexpott 🇪🇺🌍

    xjm → credited alexpott → .

  • Comment 5 days ago →
    🇺🇸United States effulgentsia
  • Comment 5 days ago →
    🇨🇦Canada star-szr

    xjm → credited star-szr → .

  • Comment 5 days ago →
    🇺🇸United States tim.plunkett Philadelphia
  • Comment 5 days ago →
    🇺🇸United States xjm

    Crediting as per triage in #3.

    Nice research @vinmayiswamy! Sorry for the very long delay in response. It does indeed look like 🐛 AJAX pager doesn't work with exposed filter which has a default value Fixed may have been a duplicate of this issue.

    The final step I would take would be to manually test this on Drupal 10.0 and confirm that the bug can be reproduced, and then again Drupal 10.1 (or even a more supported version like 10.5) and confirm the bug is no longer there.

    Once that is done, if it shows this issue fixed, we can close this issue as a duplicate.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024