Allow 'Put the exposed form in a block' setting to be used with views block displays

I queued this patch for testing against 8.1.x.

Patch working for me.

What happens if you try to place such a block using the core "Block layout" mechanism. Is the exposed block showing?

Updated for 8.2.x and 8.3.x

Updated for 8.2.x / 8.3.x

- forgot to update status to needs review [my first 'patch' - Sorry for spamming you guys <3]

Rerolled the patch against 8.3.x because #11 failed to apply.

The #8 and #11 patches seem to be quite different. With #11, it is true it applies on 8.2, but it does not work, I cannot see the option anymore on the view edit form.

I attached a new patch.

This one should apply (at least for 8.2)

One more try.

Patch from #22 works flawlessly.

Has anyone else tested this with an exposed form that has a 'Reset' button? This is what we are seeing when we try to Reset any exposed forms that are attached to a Views block.

Redirect, 404: /views/ajax?field_tags_target_id=downtown+%288%29&sort_by=created&sort_order=DESC&op=Reset

Edit: Some notes about reproducing...

The View Exposed Form setting 'Exposed form in block' needs to be set to "No" to replicate this. Using this patch, when 'Exposed form in block' is set to 'No' the exposed form still shows up and the form works, but it is attached to the top of the Views block. If the exposed form style is 'Basic' and "Include reset button (resets all applied exposed filters)" is checked, then the "Reset" button will show up.

The 'Reset' button will NOT show up at all if 'Exposed form in block' is set to 'Yes' -- this appears to be by design.

Well. It needs tests, anyway. So, yes, "Needs work".

@brantwynn sounds like you are running into #2820347: Exposed filter reset redirects user to 404 page on AJAX view when placed as a block, which is unrelated to this feature.

Some basic tests for this, basically the page test now applied to a block display.

Reroll for 8.7.x of #27

Been using #33 for a year+ with no problems on D8.7 > 8.8 > 8.9. Using #33 on new Drupal 9.0>9.1 as well. Works seemlessly.

Re uploading the patch from #33 to make sure it tests with 9.2.x

+++ b/core/modules/views/tests/src/Functional/Plugin/ExposedFormTest.php
@@ -193,12 +193,14 @@ public function testResetButton() {
   /**
    * Tests the exposed block functionality.
+   *
+   * @dataProvider providerTestExposedBlock
    */
-  public function testExposedBlock() {
+  public function testExposedBlock($display) {

This test is not clicking on any buttons. I think it is worth testing that.

I think we should test that the submit buttons work. So change the end of the this test to do something like:

    // Test that the correct option is selected after form submission.
    $this->assertCacheContext('url');
    $this->assertTrue($this->assertSession()->optionExists('Content: Type', 'All')->isSelected());
    foreach (['All', 'article', 'page'] as $argument) {
      $elements[0]->find('css', 'select')->selectOption($argument);
      $elements[0]->findButton('Apply')->click();
      $this->assertCacheContext('url');
      $this->assertTrue($this->assertSession()->optionExists('Content: Type', $argument)->isSelected());
      // @todo ensure content is as expected.
    }
    $elements[0]->findButton('Reset')->click();
    // @todo ensure content is as expected.

Addressing #39

Meanwhile: my dirty workaraound:
https://www.drupal.org/project/drupal/issues/2692297#comment-13970958

Applied patch #40 and it works fine.The exposed form in a block option will be available for block displays after applying this patch.

Before patch:

After patch:

RTBC +1

Since #39 was addressed, moving this back to RTBC. It works as designed for me also and fixes a major issue with using exposed filter blocks on non-ajax views.

Restoring status after HEAD was broken

Committed 9f8f38d and pushed to 9.3.x. Thanks!

If the View has an alternative page display, it'll default to picking the first URL it can find (even if that view might be for a different purpose e.g. for a REST API).

References:
ViewsExposedForm::buildForm()
ViewExecutable::hasUrl()

Integration with "Link display" would be useful for controlling where the form submits to, or making use of ViewExecutable::$override_url.