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 (non-ajax) 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).

As noted in #23, the problem seems to be that ::getLinkDisplay() chooses the first display that has a path. Why would it ever make sense to do this? This will often give the path of a different display and I don't see how that would ever be correct.

This was fixed in views_block_filter_block by removing the loop that searches other displays; see #2979690: Incorrect form action URL for views that have page displays.

I was able to fix it for our purposes with this:

/**
 * Implements hook_form_FORM_ID_alter().
 */
function hook_form_views_exposed_form_alter(array &$form, FormStateInterface $form_state, string $form_id): void {
  // Fix Views exposed filter form action.
  // @see https://www.drupal.org/project/drupal/issues/2844823
  $form['#action'] = \Drupal::request()->getPathInfo();
}

This is still an issue in Drupal 11.1 and it can become quite annoying for blocks with exposed filters (I use page reload, arguments, query parameters, and contextual filters in my block, no AJAX).

When the first views display item with path (page, rss, etc.) in the current view is a view with a dynamic route (like node/%node/somepage), this also leads to a routing error, like this one: Symfony\Component\Routing\Exception\MissingMandatoryParametersException: Some mandatory parameters are missing ("node") to generate a URL for route "view.viewname.page_1". in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 180 of /var/www/html/mysite/web/core/lib/Drupal/Core/Routing/UrlGenerator.php).

The root cause of the issue was described by #23 (for Drupal 9) and reinforced in #38, and a workaround was suggested in #30.

One small addition though that might help others. By default it's the first path within the current view which is chosen by the block. However, in the Pager > Link display section you can choose other displays with a path from the current (!) view as well. Only the "None" and "Custom URL" options of the Link display are not respected. (And ultimately the default None option is not respected by getLinkDisplay). So I created a random page (with the /node path), disabled it, and use this as a reference link for the block with the exposed filters.

This is probably a duplicate of #2840283: Views exposed form action incorrect when view also has a page display - there's a WIP MR up over there but as per comment 75 BC is going to be tricky for this fix.

Marking PMNMI based on #41 if anyone disagrees that this is a duplicate, feel free to reopen this and explain why. Otherwise we can close this out after 3 months.

Wanted to bump 1 more time before closing, since it had a lot of activity at one point.

Thanks @smustgrave! I added a link to this one in #2840283: Views exposed form action incorrect when view also has a page display so we don't lose this entirely!

@acbramley RE #41 I don’t think this is a duplicate of #2840283: Views exposed form action incorrect when view also has a page display, though that issue may provide a workaround in some cases.

That issue is about explicitly selecting a display. This issue is addressing a different problem. When the current display does not have a route, Views ends up guessing which routed display to use for the exposed form action.

That guess can be wrong. If the view has multiple routed displays, Views may pick a different one entirely, such as data_export, ical_feed, or any other display with a route. This leads to incorrect behaviour. In practice, it often appears to be assuming a page display 🤞

The patch here is trying to fix that underlying guessing logic so the behaviour is predictable, rather than relying on display ordering or duplication as a workaround.

Marking this back to Needs Review. I will move this to an MR shortly and try to add a test.

If the current behaviour is considered intentional, an update path that allows an unrouted display to explicitly reference a routed one may be a safer alternative.

Appears to have two MRs, both having some issues, can one be closed please

Sure, closed the one that was just #15 because I detoured a bit. I guess I forgot to submit my comment for why on the other computer...

Re #46

That issue is about explicitly selecting a display.

I'm not sure what you're referring to?

That issue is about explicitly selecting a display. This issue is addressing a different problem. When the current display does not have a route, Views ends up guessing which routed display to use for the exposed form action.

That is exactly what #2840283: Views exposed form action incorrect when view also has a page display is about too. Views guesses the first display that has a route and uses that for the form action.

@acbramley RE #52

I re-read both issues and compared the current MRs. I think you’re right that they’re effectively the same problem now: avoiding “guessed” routed displays for unrouted displays, while still honouring an explicitly configured link_display and falling back to the current page (especially for AJAX rebuilds). The newest MR 13479 are clearly converging, so treating this as a duplicate seems reasonable.

For context on my earlier hesitation: some of the earlier patches and especially MR 8053 read to me as focused on making an explicit Link display configuration work, rather than removing the implicit “guessing” entirely. That’s what initially made these feel distinct.

After revisiting the summaries and the more recent MRs, it’s clear they’re addressing the same underlying issue. I’ll close this issue, hide the patches and MR 8053, and move any relevant tests or fixes over to the other issue.

Still a bit unsure if I should iterate on MR 13479, or create a new one. I will start with a fork so I don't step on toes... too much. 👣