Return url doesn't remember the views exposed filters that I've used

This commit should fix this: http://cgit.drupalcode.org/views_data_export/commit/?id=584e8767f5a2bef2...

But it doesn't work with batched-exports.

I managed to work around this issue for my (batched) view by overriding views_data_export_plugin_display_export with my own class in which I save the exposed_input in the first 'execute' and use it in the 'render_complete' for the return url query parameters.

Note: this solution returns the user to the previous page instead of showing a return-link.

// mymodule.module
/**
 * Implements hook_views_plugins_alter().
 */
function mymodule_views_plugins_alter(&$plugins) {
  $plugins['display']['views_data_export']['handler'] = 'mymodule_views_data_export_plugin_display_export';
}

// mymodule_views_data_export_plugin_display_export.inc
class mymodule_views_data_export_plugin_display_export extends views_data_export_plugin_display_export {
  function execute() {
    $output = parent::execute();

    if (empty($this->batched_execution_state->sandbox['exposed_input'])) {
      $this->batched_execution_state->sandbox['exposed_input'] = $this->view->get_exposed_input();

      // Ensure any changes we made to the database sandbox are saved.
      views_data_export_update($this->batched_execution_state);
    }

    return $output;
  }

  function render_complete() {
    $query = array(
      'download' => 1,
      'eid' => $this->batched_execution_state->eid,
    );

    $file = url($this->view->get_url(), array('query' => $query));
    $message = t('Your export has been created. View/download the file <a href="@link">here</a>.', array('@link' => $file));
    drupal_set_message($message);

    $options = array(
      'absolute' => TRUE,
    );
    if (!empty($this->batched_execution_state->sandbox['exposed_input'])) {
      $options['query'] = $this->batched_execution_state->sandbox['exposed_input'];
      unset($options['query']['attach']);
    }

    $attach_display = $this->batched_execution_state->sandbox['exposed_input']['attach'];
    $view_url = $this->view->get_url(NULL, $this->view->display[$attach_display]->handler->get_path());
    drupal_goto($view_url, $options);
  }
}

I think the root cause is actually this in Views #2275119: views::get_url() works incorrectly when there is an argument in the path.

As far as workarounds go, another point of injection is in hook_views_data_export_batch_alter(). The $final_destination argument to that alter hook can be modified to change where 'return-url' points. That still leaves the original problem of getting the URL to the view with the arguments applied, but at least there's an injection point that's easier than duplicating the entire export plug-in just to override the behavior.

For example, in our case we just want to remove the buggy link until this ticket is addressed:

/**
 * Implements hook_views_data_export_batch_alter().
 *
 * This works around #2119373 (which appears caused by #2275119) in which
 * the "Return to previous page" link on the batch export results page takes the
 * user to the search page without any filters applied.
 */
function my_module_views_data_export_batch_alter(
                                    array &$batch, array &$final_destination) {
  // Remove erroneous return URL to avoid frustrating users until #2119373 is
  // addressed
  unset($final_destination[1]['query']['return-url']);
}

As a side note, it appears that for a view we are using this with that has exposed filters, request_uri() inside our hook_views_data_export_batch_alter() contains the full URL of the export display/page with the exposed filters applied (i.e. our normal page display path is /search and the export page is /search.csv, so the request URI ends up being /search.csv?arg1=arg1_value&arg2=arg2_value, etc.). Given that, a possible workaround might be to reconstitute the correct return URL from a combination of the normal display path and the query string parameters passed in the request URI of the export display/page. Maybe even a string replace of the export page for the normal page URI would do the trick, for now, until the root cause of this issue in Views can be addressed.