Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
After installing module views_block_filter_block each view rendered with exposed form even if no exposed filters available. I see just Apply button without any filter field. To prevent it i should set Exposed form in block:Yes as workaround, but it is not real solution.
Proposed resolution
As i could see in src/Plugin/views/vbfbPluginDisplayBlock.php there is overridden method
public function usesExposed() {
return TRUE;
}
It forces to render exposed form even if no exposed filters used.
Probably it should check
if (!isset($this->has_exposed)) {
....
}
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | empty_exposed_forms-2790505-19.patch | 881 bytes | yogeshmpawar |
| #10 | empty_exposed_forms-2790505-10.patch | 854 bytes | hamrant |
| #2 | empty_exposed_forms-2790505-2.patch | 934 bytes | denis_kv |
Comments
Comment #2
denis_kv CreditAttribution: denis_kv at Skilld commentedComment #3
andriyun CreditAttribution: andriyun at Skilld, Drupal Ukraine Community commentedComment #4
denis_kv CreditAttribution: denis_kv at Skilld commentedComment #5
andypostI think state should not be cached in plugin
Comment #6
andypostI think module should add option to configure path (user entered or current page) also it should take into account that core uses "linked display" to provide path so block has exposed form
Comment #7
ndeet CreditAttribution: ndeet at Zensations commentedHi,
thanks the patch works to only expose forms which are actually configured.
Agree with andypost, an option to specify if the view path or current page would be nice too, probably another issue. I solved it now by altering the form (hook_form_views_exposed_form_alter()) and setting the action to the page manager page containing the views block.
Comment #8
renukakulkarni CreditAttribution: renukakulkarni commentedComment #9
gajanannehul CreditAttribution: gajanannehul as a volunteer and at Clarion Technologies commented#2 works for me.
Comment #10
hamrant CreditAttribution: hamrant at DEWEB Studio, Drupal Ukraine Community, FFW for Drupal Ukraine Community commentedMore simple solution
Comment #11
joverI can confirm patch #10 works.
Comment #12
csedax90 CreditAttribution: csedax90 commented#10 works like a charm
Comment #13
CulacovPavel CreditAttribution: CulacovPavel commentedPatch number #2 is more perfect. confirm patch #2
Comment #14
yogeshmpawarPatch #10 working for me as well. Simple & Straight.
Comment #16
yogeshmpawarCommitted & pushed to 8.x-1.x branch also assigning credits.
Comment #17
arosboro CreditAttribution: arosboro commentedI don't know what you guys are testing with, but patch #10 hides all views results. Negating $this->options['exposed_block'] returns the results in the view. I was using patch #2 before this was committed and was happy with it. Simpler isn't always better.
The last 2 commits related to usesExposed() absolutely stopped me in my tracks while I was working on a project.
Comment #18
arosboro CreditAttribution: arosboro commentedjust frustrated, sorry if I came off as being crass. Have a great day whatever you do.
Comment #19
yogeshmpawar@arosboro - Thanks for the immediate reply, Here's the updated patch will solve all the issues related to issue.
Also the AJAX Issue is solved in this patch.
Comment #21
yogeshmpawarCommitted & pushed to 8.x-1.x branch also assigning credits.
Comment #22
arosboro CreditAttribution: arosboro commentedI appreciate the quick response. I will test the latest dev branch on my project to ensure views behaves as advertised.
Comment #23
arosboro CreditAttribution: arosboro commented@Yogesh Pawar This last commit 2c65ce2 resolves the issue I had experienced in the past two updates. Thank you!
Comment #24
yogeshmpawar@arosboro - Thanks to you also for pointing this issue.