Views exposed form action incorrect for embedded views' displays with other displays with paths

Moving to the right queue. Didn't attempt to reproduce.

I'm still seeing this issue in 8.7.x. A somewhat similar issue is mentioned in #8 from #2820347: Exposed filter reset redirects user to 404 page on AJAX view when placed as a block, but was not addressed by the patch there.

Following-up on #8 from #2820347: Exposed filter reset redirects user to 404 page on AJAX view when placed as a block:

In my view I had several blocks with exposed filters that worked until I added page display's. From that moment the exposed filters on the blocks started using the path's of the first page display in the form action, instead of the "current page".

I don't really understand why the code in views gets to decide where to redirect the form action to. "If it doesn't find a display with a path, redirect to current page". It seems so random to me.

The attached patch avoids selecting a routed display for the form action when the display is not a routed display. Let's see what the testbot has to say about it.

It appears that this logic is relied upon in some areas. Until a stable fix can be achieved, the form's action can be overridden to the correct path if it is known.

For instance:

$form['#action'] = Url::fromRoute('<current>')->toString();

Updated the issue summary with new behavior after #2820347: Exposed filter reset redirects user to 404 page on AJAX view when placed as a block.

The problem from #15:

1. was first mentioned in #2820347-8
2. the current issue summary about a fall back to the first routed display was described in #2820347-87
3. confirmed later in #2820347-123
4. and suggested in #2820347-126 that this is not a bug but intended behavior.

To summarize, the current issue title #2844823: Views exposed form action incorrect for embedded views' displays with other displays with paths is a duplicate of #2820347: Exposed filter reset redirects user to 404 page on AJAX view when placed as a block. However, the issue went into another direction (starting from #14).

@bobbygryzynger, would you like to use this issue and argue #2820347-126? If so, could you please update the issue title/summary to match the new goal?

This happens as well in D7

This still happens and is easy to reproduce, I just bumped into this issue while using views_data_export which caused the Reset button to trigger the download of the export, quite a confusing bug!

The issue is the same though, the action is set to the export path rather than the current page.

The bug comes all the way from Drupal\views\Plugin\views\display\DisplayPluginBase::getLinkDisplay where it simply chooses the first display that has a path. The flow is:

1) ViewsExposedForm::buildForm calls $view->hasUrl
2) ViewExecutable::hasUrl calls DisplayPluginBase::getRoutedDisplay
3) getRoutedDisplay calls getLinkDisplay which checks the link_display option (this is used by views displays with the "View more" logic and probably other things). However, if this is empty it just finds the first display with a path and returns that

I tried #15 and it has fixed the form action on a view block with exposed filters + AJAX enabled.

Update: I only noticed comment #17 afterward, so I will override the <form action> in a hook instead.

Using a hook as suggested in #17 does fix the action on the initial page load.
<form action="/current-page">

However, after using a filter (and ajax enabled), the exposed form is updated via javascript and then the action is changed to /views/ajax.
Using the reset button on the form is then broken.
<form action="/views/ajax">

For anyone still running into this problem, my workaround was to duplicate the page display that was being unintentionally used to set the path for the embedded Views displays. Then, I disabled the original page display and my embedded displays started setting the form action correctly (with or without AJAX).

As I think it is related to this issue, I wanted to note that I have posted a potential solution (more of a workaround, really) in a different issue thread: https://www.drupal.org/project/drupal/issues/1109980#comment-14414629

To save you clicking through if not wanted/needed, the gist of my comments are below.

On our project using Drupal Core: 9.3.5, on an Export CSV view attached to a Block view the latter of which is using Better Exposed Filters, the 'Download CSV' button was working fine, but the 'Reset' button also triggered the CSV download. This was the code that "solved" the problem for me:

(function ($, Drupal, drupalSettings) {
  Drupal.behaviors.resetButtonBehavior = {
    attach: function (context, settings) {
      $(context).find('.views-exposed-form input[data-drupal-selector="edit-reset"]').on('click', function(){
        window.location.replace('https://' + window.location.hostname + window.location.pathname);
        return false;
      });
    }
  };
})(jQuery, Drupal, drupalSettings);

The compromise is that the page reloads rather than just resetting the filters, but this is certainly better than the faulty behaviour of the 'Reset' button beforehand. I still feel a better solution needs to be incorporated into Core at some point.

#1874838: Allow exposed blocks to use 'Link display' settings seems to be a good solution to this issue in some circumstances.

For example I am rendering a view with a Block display which also has a Views Bulk Export display.

The Block display has filters and Views Bulk Edit on it.

The <form action> attribute will automatically get the Views Bulk Export route on it, because the block is not routable.

If I use the patch from #1874838: Allow exposed blocks to use 'Link display' settings, I'm able to set the path of the real route embedding this page, so it does not pick up the export path. The <form action> attribute will have the value of the custom path.

I am embedding a views block in paragraphs, and this code works for me (using hook_form_FORM_ID_alter() ).

if ($form['#id'] == 'views-exposed-form-marketplace-entries-marketplace-entries-block') {
    $input = $form_state->getUserInput();
    $custom_action = $input['custom_action'] ?? Url::fromRoute('<current>')->toString();
    $form['custom_action'] = [
      '#type' => 'hidden',
      '#value' => $custom_action,
    ];
    $form['#action'] = $custom_action;
  }

I found this issue right after submitting a new one, darn.
#3346820: On views with AJAX enabled, exposed filter "reset" causes page load

I'm not closing my new one quite yet, though, for a few reasons (in no particular order):

1. I think the fact that the reset button causes a page load when AJAX is enabled is the root cause of the issue -- I think even on a view page display, hitting Reset shouldn't cause a page load, right?
2. When I reproduce the issue, the form action is the view page display URL from the start, not just after I submit filters.
3. I think my steps to reproduce are simpler? (but if folks agree and if the issue I created is closed as a duplicate, I could easily copy those steps to reproduce into here).