"Apply" exposed filters button starts batch export

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.

Also just ran into this issue while I was patching the button style on a different issue ticket. I fully thought my patch had caused this until I took it off and realized it was still happening.

We have the export button attached to a block display of our view and enabling AJAX on the block fixed this.

I will say that, when I was researching trying to fix this, I was looking at the `src/Plugin/views/display/DataExport.php` file and specifically looking at the buildResponse() function, which calls the buildBatch() function. This overwrites the existing `buildResponse()` function that gets called in docroot/core/modules/views/src/Routing/ViewPageController.php.

Which basically means, anytime there's a view response object being returned (i.e. when a views filter form is submitted), the export logic is getting run.

I've been taking a crack at trying to fix this by adding a conditional in the buildResponse() function to check to see if the response is triggered by the Export button and NOT something like the Apply button. I have gotten it fully working yet, but it does seem to be the root of what's happening.