"Apply" exposed filters button starts export instead of filtering

I'm marking this as Major, because even if the data export display is not attached to the default display, the default display's Apply filter button still performs the export instead of filtering. So I cannot even figure out how to work around the problem. Maybe if you have two separate views duplicating the functionality, and embed one that doesn't have a data export display while having an export link to one that does, that could work?

You may need to provide a page display too (with path test in this example). I'm not positive, but since the view only has a single path (test/export) the exposed filter form might be picking that to submit to. You can check by inspecting the exposed filter form in the browser and checking the action attribute of the form element.

Run into the same problem, for me it was including a block view display inside a custom twig template, something like this:

{{ drupal_view('my_view', 'block_1') }}

The Form action was set to the views_data_export download path, not to the path of the current page.

I solved this via a simple form_alter:

function my_module_form_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {
  if ($form["#id"] === 'my-exposed-form-id') {
    $form["#action"] = str_replace('/download', '', $form["#action"]);
  }
}

The only reason there's no Page display is because I created an minimal verifiable example. The issue occurs even if you add a Page display.

@daveiano I found a more general workaround:

/**
 * Implements hook_form_FORM_ID_alter().
 */
function mymodule_form_views_exposed_form_alter(array &$form, FormStateInterface $form_state, string $form_id): void {
  $path = Url::fromRoute('<current>')->toString();
  $form['#action'] = $path;
}

I'm having the same issue.

We have the same problem in connection with exposed filters. The bug is rather critical, as the respective view can no longer be used.

In order to use the workaround provided you need to include use Drupal\Core\Url; in the custom module. Added to the workaround example in issue summary.

These issues may be related to this one:

https://www.drupal.org/project/views_data_export/issues/3166881 🐛 Data Export path is being set as the action for exposed filters form when using views_embed_view() Active
https://www.drupal.org/project/drupal/issues/2840283 🐛 Problem with action path for embedded forms Needs work

The patch #42 from tbenice works for me :
https://www.drupal.org/project/drupal/issues/2840283#comment-13515227 🐛 Problem with action path for embedded forms Needs work

Following the advice of @kiwad in https://www.drupal.org/project/views_data_export/issues/3166881#comment-... 🐛 Data Export path is being set as the action for exposed filters form when using views_embed_view() Active , I turned on AJAX for the views block display (to which the export is attached) and now the exposed filter works and does not trigger the download.

Following the advice of @kiwad in https://www.drupal.org/project/views_data_export/issues/3166881#comment- 🐛 Data Export path is being set as the action for exposed filters form when using views_embed_view() Active ..., I turned on AJAX for the views block display (to which the export is attached) and now the exposed filter works and does not trigger the download.

This works! In the view configuration:

Use AJAX
Options such as paging, table sorting, and exposed filters will not initiate a page refresh.

If you want to do a general workaround and have it work when Use AJAX is enabled, you will need to use this, instead of what I shared in #8:

use Drupal\Core\Form\FormStateInterface;
use Drupal\Core\Url;

/**
 * Implements hook_form_FORM_ID_alter().
 *
 * Workaround for views data export running on exposed filter form submit.
 * https://www.drupal.org/project/views_data_export/issues/3341736
 */
function MODULE_form_views_exposed_form_alter(array &$form, FormStateInterface $form_state, string $form_id): void {
  $current_request = \Drupal::request();
  $previous_url = $current_request->server->get('HTTP_REFERER');
  if ($previous_url === NULL) {
    $path = Url::fromRoute('<current>')->toString();
    $form['#action'] = $path;
    return;
  }

  $uri_parts = parse_url($previous_url);
  if ($uri_parts === FALSE) {
    return;
  }

  $path = $uri_parts['path'];
  $form['#action'] = $path;
}

In my opinion, none of the suggested workarounds are good enough to warrant closing this issue.

I updated the workaround code in #17. It should work whether coming from another page to the view display or from the same page, and it works whether using AJAX or not.

I have this issue, landed here trying to solve it.