Exposed Filter in Views Redirects to Page Display Path Instead of Block Path

Hi, As a workaround, you can use the setting available under Advanced called "Use AJAX." Setting "Use AJAX" to "yes" will resolve the issue for now.

This is by design, Views will look for the first display with a path and use that. You can try #2 or make the block and page be separate Views and not 2 displays on the same View.

I'm sorry, but if this is "works as designed" then I think this is poorly designed. Please explain to me why I'd want the exposed filters in my view block to target another random display in that view. You said it uses the "first" display with a path, but it doesn't use the first display according to the configured display order within the view, it uses the first display defined in the view's YAML config file.

If this works as expected with a view containing only a single block, then it should work the same with a block in a view that also contains other displays.

There's a similar problem if you enable Views Bulk Operations on a view embedded as a block. The bulk operations also incorrectly target the wrong page path. However, in this case, enabling AJAX doesn't work as a workaround. So you're telling me that now I need to recreate this block in a completely new separate view and reconfigure my pages/blocks just because I've added bulk operations and this is by design?

Reopening because you shouldn't need to completely reconfigure your views just because you add bulk operations to a certain display.

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

I went through exactly the same issue, including VBO and ajax not resolving this. Only thing to add that I started with an embed display, same thing, then switched to block.

Also agree with richarddavies that "by design" is a bit of a stretch. I have not come across other situations where different displays inherit properties without there being a way to overwrite it per display. I get that there is no page path on a block or embed where I could possibly overwrite it, but in that case it should be implied, not borrowing from another display without any indication that it's doing so.

IF a redirect path is required in scenarios like exposed filters and VBO, maybe this could be a setting with replacement patterns? And even if ajax is solving the exposed filters case, most users will see ajax as an option, not a requirement I'd say.

Hello,
I've checked the problem and I have an approach for that,
1) we can enable AJAX for the View
- In the Advanced section, locate the Use AJAX setting and set it to Yes.
2) Configure the Exposed Form as a Block
- Go to the advanced section and set the Exposed form in block to Yes.
3) Modify the Form's Action Attribute
- We can Implement hook_form_alter() in the custom module to change the form's action URL and set the form's action to the current
page's URL.

Thank you!

I'm encountering a similar issue. The view functions correctly when AJAX is enabled, but when submitting an exposed filter with AJAX disabled, the form redirects to an incorrect path.

The affected view is a page display that uses a contextual argument, and the exposed filters are placed in a block using the Better Exposed Filters (BEF) module, using datasources from a Search API index.

By modifying the form's action attribute using hook_form_alter(), I was able to redirect to the correct path (Thank you Ishani). However, I see this as more of a temporary workaround, it can become quite cumbersome if it needs to be applied across multiple views.

Drupal Core: 10.4.5
BEF: 7.0.5

This "design" functionality is bad design, especially if you are updating from an earlier version of Drupal. This breaks legacy views that have multiple displays with exposed filters in a single view. As noted above, simply setting AJAX to "Yes" isn't always a fix. We have to rebuild almost every view on every Drupal site we run and grow our number of views exponentially, or write tons of hook_form_alter case statements to target all the different exposed forms so they redirect properly, because of this new design decision.