Views pager links incorrectly handle complex exposed filters

I was facing the same issue for a custom view in D8 and wrote a patch which i hope solved the problem

Sorry, wrong path in patch, this one works:

@dev.tim may be drupal version but i am not sure, i have created patch, thanks

This still needs a test.

Also this seems to change the output URL in such a way that empty parameters are lost, which is good probably, but its why the test fails in #5

-'?status=All&type=All&langcode=All&items_per_page=5&order=changed&sort=asc&title=&page=2'
+'?status=All&type=All&langcode=All&items_per_page=5&order=changed&sort=asc&page=2

@dev.tim - do you think the patch for Drupal 8 in your comment above (#5) will work for my D8 issue: https://imgur.com/O0saE4i (apologies if this is not the proper place to ask this - but if the patch might be viable - I'm more than willing to test it on a dev server.) The patch (@dev.tim #5 above) did work for my site: Drupal 8.5.5 | PHP 7.1.19 | 5.5.5-10.1.34-MariaDB

Use the patch in #5 against Drupal 8.5.6 and it applied cleanly, and fixed the issue with my checkboxes not persisting across pager links. I also am using an ajax form and Better Exposed Filters 8.x-3.0-alpha4.

This seems like an easy fix (says the non-programmer). Any reason why this has not been implemented - or is it more complicated than that?

What is required for this to be merged into core for the next release? Views pagination is currently broken because of this so it really needs to be resolved.
As Lendude mentioned in #9 the reason this patch failed was because it removed the empty get paramaters from the request url. Should this patch be updated to include the empty paramaters or should the test be updated to not care about the empty paramaters? I can get this fixed and a new patch uploaded but I need clarification on the above question.

@jagermonster From my reading of the issue - #9 needs to be addressed and a new test needs to be added to cover the bug this issue fixes before this can be put back into review and eventually marked as RTBC.

I have found the actual problem that cause the issue in the first place.
In core/modules/views/src/Form/ViewsExposedForm.php line 178 there is some code that looks like it resolves another issue with checkboxes

    foreach ($values as $key => $value) {
      if (!empty($key) && !in_array($key, $exclude)) {
        if (is_array($value)) {
          // Handle checkboxes, we only want to include the checked options.
          // @todo: revisit the need for this when
          //   https://www.drupal.org/node/342316 is resolved.
          $checked = Checkboxes::getCheckedCheckboxes($value);
          foreach ($checked as $option_id) {
            $view->exposed_raw_input[$key][] = $value[$option_id];
          }
        }
        else {
          $view->exposed_raw_input[$key] = $value;
        }
      }
    }

This code changes the array keys. e.g. for a date exposed filter created[min]=21/01/2018&created[max]=22/01/2018 gets changed to created[0]=21/01/2018&created[1]=22/01/2018
So the index min and max are changed to 0 and 1
It seems that the issue described in https://www.drupal.org/node/342316 has been resoved on Drupal 8.7-dev

This bug can be fixed by removing that checkbox code so it becomes

 foreach ($values as $key => $value) {
      if (!empty($key) && !in_array($key, $exclude)) {
          $view->exposed_raw_input[$key] = $value;
      }
  }

I've found the patch posted to already closed issue - 2943163#16.
This works for me with Drupal 8.6.7.
URLs look consistent for filters and for filters+pager links.
I'm wondering why it's not posted to some open issue and not considered to merge. Maybe I've missed something?

Seems like a patch which I've mentioned in #18 just fixes small inconsistency. But globally we still this trouble. It does not work properly if we have checkboxes inside of subvalue of exposed filter. So I propose to make views exposed raw input handling recursive. Attaching the patch. At least it works for me.

This issue also applies to the proximity filter from the Geofield contrib module. Currently the pager is not usable with that filter, and the patches here fix that.

The patch in #5 works well for me (and #8 seems to be identical). It's simple, easy to review, and reuses an existing method.

The patch in #19 mostly worked. However I got an unwanted extra query parameter from a field that was not actually exposed. The changes from this patch are complex.

@mpolishchuck Please can you explain why you posted patch #19? Do the earlier patches not work for your scenario? If so, please can you upload an export of the view config (simplified as much as possible) where #5 fails, but #19 works?

The next step for this issue is to add a test. A good starting point would be a view that causes this bug - using core only and simplified as much as possible. If anyone has an example, please upload a file with an export of the view config.

An workaround for me for Date range is using 2 filters "From" and "To" instead of 1 with "Between".

So the patch in #5 uses ViewExecutable::getExposedInput which pulls directly from the request and could contain other non-filter related query parameters (it simply excludes page and q). It also pulls data from the session if nothing is given locally.

1. It will preserve non filter related query parameters which is probably a good thing
2. It will only use session data if there are no additional query parameters which is probably OK

#19 is handling recursively processing the values, but explicitly uses the processed raw input (yes, a bit of an oxymoron). I'm not sure which should be the 'right' approach...

#5 works nicely in my case where I am using the geofield proximity filter.

Is there a chance this has been fixed in Drupal 8.7.0?

I saw no reference to it in the release note - but the problem did not recur after updating to D 8.7.0. I did not have to go back in and apply the patch, #5 above, to the site after updating.

I did confirm that the un-patched code does still exist with the new Drupal version, so the thought seems to be that a change was made elsewhere that made the un-patched code function properly? I'm guessing, but was hoping someone else would take a look at it.

@CB1_Dru1 maybe #2987598: View's pagination doesn't carry the exposed filter value had an effect on this? If you can't reproduce this anymore, please feel free to close this issue.

Is there a chance this has been fixed in Drupal 8.7.0?

@CB1_Dru1 Confirmed - now works for me without the patch for geofield proximity filter.

Looks like this has been fixed by #2987598: View's pagination doesn't carry the exposed filter value

@lendude - I see it's been marked as fixed. Awesome!