Allow exposed form to preserve URL query parameters

Some test coverage would be sort of nice.

+++ b/core/modules/views/src/Plugin/views/exposed_form/ExposedFormPluginBase.php
@@ -276,6 +285,28 @@ public function exposedFormAlter(&$form, FormStateInterface $form_state) {
+      foreach (\Drupal::request()->query->all() as $name => $value) {

You can use $this->view->request instead.

Reapplied patch #8 to the 3.x branch

Any Update on this issue ?

I was having issues using this with facets. The facet identifier (like f[0]) was being double encoded and not recognized. I fixed this by decoding the name of the hidden form element.

#15 worked for me! Thanks.

This patch needs tests, but it works great in production.

Reroll of #15

Reroll of #23 with an additional !empty() check to prevent issues on views without this option set.

Patch #25 works well for me.
Tested with 9.3.9 core version.

Re-rolled #25 for 9.4

I was just investigating the exposed form and query parameters and found out this issue. Thanks for all the work done.
It is working for me in the following situation:

• Exposed form (Simple search form)
• Exposed sort form (Views exposed sort block)
• Facets

1. +++ b/core/modules/views/src/Plugin/views/exposed_form/ExposedFormPluginBase.php
   @@ -103,6 +105,22 @@ public function buildOptionsForm(&$form, FormStateInterface $form_state) {
   +
   +  public function submitOptionsForm(&$form, FormStateInterface $form_state) {
   

   This method should have an @inheritdoc.

2. +++ b/core/modules/views/src/Plugin/views/exposed_form/ExposedFormPluginBase.php
   @@ -273,6 +291,29 @@ public function exposedFormAlter(&$form, FormStateInterface $form_state) {
   +    if (!empty($this->options['preserve_url_query_parameters'])) {
   +      $query = \Drupal::request()->query->all();
   +      foreach ($this->options['preserve_url_query_parameters'] as $name) {
   +        if (!isset($form[$name]) && isset($query[$name]) && ($value = $query[$name]) !== '') {
   +          if (is_array($value)) {
   +            foreach (explode('&', UrlHelper::buildQuery($value, $name)) as $param) {
   +              list($name, $value) = explode('=', $param);
   +              $form[rawurldecode($name)] = [
   +                '#type' => 'hidden',
   +                '#value' => rawurldecode($value),
   +              ];
   +            }
   +          }
   +          else {
   +            $form[$name] = [
   +              '#type' => 'hidden',
   +              '#value' => $value,
   +            ];
   +          }
   +        }
   +      }
   +    }
   

   This code doesn't look right. Even though there is some protection because a user has to enter the list a of query parameter names in the URL, I'm really not sure about allowing stuff from query parameters to become $form array names. If you manage to do # something then all sorts of interesting things become possible.

3. We still need automated test coverage of the new feature

We've been using patch #23 for years and it's worked great for us. However, I'm building a new View with an exposed filter (no facets) that I want to use with Better Exposed Filters. With this patch in place, I cannot save the BEF settings to properly enable it. I get past the first page to choose it as the style for exposed forms, but cannot save the next settings page where you choose the widget for each exposed filter. The following error appears in the logs.

TypeError: explode(): Argument #2 ($string) must be of type string, array given in explode() (line 120 of /docroot/core/modules/views/src/Plugin/views/exposed_form/ExposedFormPluginBase.php)

If I remove the patch things work as normal, but of course, our page with facets on now breaks.

If I enable BEF with the patch removed, then add the patch back afterwards, the Views-generated page throws a fatal error and I once again cannot save the BEF settings:

Error: Cannot create references to/from string offsets in Drupal\Component\Utility\NestedArray::setValue() (line 155 of /docroot/core/lib/Drupal/Component/Utility/NestedArray.php)

This happens with both BEF 8.x-5.2 and 6.0.1, running on Drupal 9.3.22 with either patch #23 or patch #25.

Added method doc comment as per #32

Added a few lines to 2681953-29.patch to prevent empty params showing in the URL.

@itaran, why did you work with an older patch? Why is there no interdiff for the reviewers to easily see what is changed? And you did not follow the suggestions alexpott made...
So we have no idea in what state your patch is in...

Tested #34 with Facets. Steps:

1. Go to edit the views of interest
2. Expand "Advanced" section
3. Click "Exposed form style: Settings"
4. Put f in the Preserve query parameters from URL
5. Save and clear cache

It works.

Tested #36 Works Great (this feature should definitely be added)

+1 (awesomesauce) saved me from having to use hook_form_views_exposed_form_alter() to modify the submitted query parameters for the exposed filter.

Specifically useful when having other view blocks on page that use contextual filters with setting "provide default value" -> "Type: Query parameter" which updates the content in those blocks when the set parameters are passed by URL from custom links that provide those additional parameters.

#36 works for me as well.

I've added the code back from #34 and created an interdiff with #36.

Still need to address point 2 and 3 from #32

Patch from #42 is working well for me, we have a search implementation that has custom query parameters that were being lost on exposed form search. Although that's not specifically facets, but I believe the issue is the same.

The patch in #45 applies and works with D10.2.5.

With a Exposed form style:Basic (Exposed form in block:no)

Just for completeness if others are looking for orientation:

It does not work with: Basic (with layout) from the https://www.drupal.org/project/vefl module.

For BEF there is an extra patch based on this patch. https://www.drupal.org/project/better_exposed_filters/issues/3119947#com...

The extra empty parameter check from #36 and added in #42 broke the handling of array parameters (such as facets) for me. I've fixed it by first cleaning the variable mixing and then deleting this check as It looks to me that is already handled in
if (!isset($form[$name]) && !empty($query[$name]) && ($value = $query[$name]) !== '') {

The existence of this patch initially troubled me into thinking I need this patch but for the specific use case this issue was created I think we are already fine using the Search API module. Unless you are using facets without indexed views (using search_api) which I think is not possible...

The functionality was already built in #2378945: Facets are lost by Views on keyword search and it's provided - without using any patches - in the Query settings form:

So the main question here is... do we still need issue?

Another use case where this patch is useful: https://www.drupal.org/project/calendar_view/issues/3403103

I add #3403103: Stay on same month/week after exposed filtering as a related issue then. But if we are to do anything in Drupal core, we have to update the issue summary since the initial one (using search_api & facets) is not valid anymore.

I create this patch ONLY for Drupal V10.3.1

Patch include the update for this files:

views.data_types.schema.yml
ExposedFormPluginBase.php

Added support for Reset button.

Wanted to bump 1 more time for an IS update before closing.

I asked about this to one of the view maintainers and summary will need to be updated for a modern use case. Appears it was useful for facets at one point but no longer the case. New features typically need to hit a 80% usefulness for others and this right now does not feel like that.

Will leave open for others to update or respond but may be closed in 3 months.

The patch does not look overly complex... so lines of code vs usefulness is more than reasonable.

And it is any use case where you need to have an URL-based integration, parameter passing to a form or a filter that you want to call multiple times or just views development, where you make changes to a view and want to test with the same parameters again, without manually entering them each time you test the changes you made ...