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.
I'm having a problem with the exposed filters in block display. When I put a value into the filter, the result set doesn't modified. This is a "less than, or equal" filter. I haven't this problem in the default or page display only in the block display.
I use the following version of modules:
drupal 6.15
cck 6.x-2.6
views 6.x-2.8
(ubercart 6.x-2.2)
Is this a bug or am I doing something wrong?
Thx,
Miamano
Comments
Comment #1
Miamano CreditAttribution: Miamano commentedI try find solution to my problem, but I thing this is a bug. In default or page display the SQL query does not contain the empty filters, only in block display.
See:
page display:
WHERE (node.status <> 0) AND (node.type in ('product', 'product_kit'))
block display:
WHERE (node.status <> 0) AND (node.type in ('product', 'product_kit')) AND (uc_products.sell_price <= 0)
The sell price filter is empty in both cases.
Comment #2
merlinofchaos CreditAttribution: merlinofchaos commentedBlocks only support exposed filters when using AJAX.
Comment #3
Miamano CreditAttribution: Miamano commentedThank you merlinofchaos! It works perfectly now.
Miamano
Comment #4
mattez CreditAttribution: mattez commentedThank you merlinofchaos! BIG HELP.
*BUT*:
now it works realy fine for me only in LIVE PREVIEW,
but when I put the block to display in some region on page (via block administration - no embedding directly with PHP) its NOT working again!? :/
Drupal 6.15
Views 6.x-2.x-dev 2010-Mar-13
or I've even tried
Views 6.x-3.0-alpha2 2010-Jan-26
When I check Firebugs Console the content of tab "Response" is looking good, with right data, but unfortently the content on page doesn't change.
THANX for any hint.
Comment #5
mattez CreditAttribution: mattez commentedNOW I try it on another site, ad it works great... I'm going to search for my fail somewhere in code...
Comment #6
mattez CreditAttribution: mattez commentedMy problem is SOLVED. I modified / simplified views-view.tpl.php. And I delete some "unused" CSS classes. :)
My TIP: Leave view-dom-id-<?php print $dom_id; ?> as view div class. It is essential for get this (IMHO views with Ajax) to work.
I leave there this:
Comment #7
Natalie-1-1 CreditAttribution: Natalie-1-1 commentedHow do you turn AJAX for blocks on?
Comment #8
eaochoac CreditAttribution: eaochoac commentedIn my case it was a confict with hierarchical select module, Just disabled and now it works.
the syntoms:
Shows perfect in block preview , but in the real block just shows the ajax clock.
Natalie you can enable Ajax in edit View -> basic setting -> Use AJAX: yes
Comment #9
minneapolisdan CreditAttribution: minneapolisdan commentedThanks for your tip, mattez, about the view-dom-id as the view div class. That solved the problem I was having.
Comment #10
acushla CreditAttribution: acushla commentedHi,
I was facing the same issue. Actually I had a view with a page display. While selecting the block region I found 2 Exposed Form blocks, one for the default view and one for the page view. I realised that the default view filters work beautifully even on a page view while the page view filters do not respond.
Hope it helps,
Rajat
Comment #11
gabriel.achille CreditAttribution: gabriel.achille commented+1: Thank you merlinofchaos!
gab
Comment #12
tmsimont CreditAttribution: tmsimont commentedI'm sorry to re-open what was marked as closed, but this really seems like a bug to me.
I lost quite a bit of time trying to expose a filter on a block view, and nowhere in the admin pages does it say anything at all about the fact that it won't work without ajax... What if you don't want to depend on AJAX for the end-user's filtering options? Everything else about basic views and block views work without the AJAX option (e.g. click sorting on table headers). Why would this not work?
It seems like it would be fairly simple to just adjust the action of the filter form to get this to work on a block. I don't think it makes sense to make such a simple thing depend on AJAX. If that is in fact the design, then it shouldn't be possible to expose a filter as a block unless ajax is active, or there should be clearer help text on the fact that it won't work without AJAX.
Comment #13
dawehnerUpdate status to something useful. In general in views2 this will definitive not be change anymore
The problem with exposed filters in blocks are the fact that blocks don't have the classical thing call url/page so they can easy interfere with formulas on the actual page.
Comment #14
tmsimont CreditAttribution: tmsimont commentedEven if you do activate "use AJAX" -- then when a user hits the page and tries to use the filter without javascript, the filter takes the user to the front page... this is definitely a bug if it causes the site to break for end-users....
Comment #15
tmsimont CreditAttribution: tmsimont commentedhmm that makes sense, but there' still a problem here... what should the status be?
Comment #16
tmsimont CreditAttribution: tmsimont commentedpager and table sort both work without ajax. i know that it "might" interfere with other elements on the page, but i think an issue of query string conflict is up to the developer to solve -- this is why in the exposed filter you can designate what to call the query string variable.
Comment #17
dawehnerUpdate status to not confuse myself again.
Comment #18
tmsimont CreditAttribution: tmsimont commentedI found a "fix" that should probably be scrutinzed:
in views_plugin_display_block.inc:
I just commented out the dependency for ajax in
uses_exposed()
and added an override forget_path()
to pull in the dynamic location of the block, identifiable by the q parameter. The downside, of course, is that this will nuke any other query string. Therefore, it needs some work... For my purposes, I don't care about other query strings, so I might not work on it. The key for anyone interested in moving forward would be to alter the return ofget_path()
to have it respect any queries (not including filter queries) that were also set -- probably not too difficult.Comment #19
tmsimont CreditAttribution: tmsimont commentedUnfortunately, setting
get_path()
has negative consequences on the "more link" that is not set without a page view, but become set with the presence of the function in a block that really shouldn't have a page.Comment #20
tmsimont CreditAttribution: tmsimont commentedperhaps this should just be a documentation thing? help text on the "Expose this filter to visitors" checkbox would clear this up:
"Exposed filters will not appear on block displays unless 'Use Ajax' is set to TRUE"
also, when I was testing this in 6.x, if a user hits the site without JS, and the "use ajax" setting is enabled, the form element still appears, and the form action is the homepage, which means if the user tries to use the exposed form they will end up on the homepage after submitting it. after looking at the 7.x code, it sure seems that this will still happen
For posterity: panels seems to be the solution here if you are looking for a way to embed a view onto a page without making that view an actual page view (you can set up a panel view to inherit its parent's URL for exposed filters, etc)
Comment #21
Garrett Albright CreditAttribution: Garrett Albright commentedOkay, I was just stumped on this for a while. Definitely, some help text needs to appear somewhere, or maybe remove the "Exposed form" section of the Views UI form for situations in which the form can't actually appear. =[
Comment #22
brandy.brown CreditAttribution: brandy.brown commentedThank you!!!
Comment #23
ForTheWin CreditAttribution: ForTheWin commentedHas anyone run into an issue where their filter results get displayed in nested divs? I am trying to create a page that displays a bunch of resources with a filter to allow the end-user to sort the resources by type. I am using the following versions:
- Drupal 7.28
- Views 7.x-3.8
- Semantic Views 7.x-1.0-alpha1
- Bootstrap 3
VIEWS SETTING:
- Format: Semantic Views
- Show: Semantic Views: Fields
- Filter Criteria: Content: Resource Type (exposed)
- Exposed form in block: Yes
- Exposed form style: Basic
- Use AJAX: Yes
The functionality works and the results are displayed based on what's selected in the resource type drop-down filter. However, the results are displaying in nested divs each time the form gets submitted and I can't figure out why. :(
SOURCE CODE BEFORE SUBMISSION
SOURCE CODE AFTER 1st SUBMISSION
SOURCE CODE AFTER 2nd SUBMISSION
To theme the exposed filter as a block, I did the following:
copied the ‘views-exposed-form.tpl.php’ file in sites/all/modules/views/theme and pasted it in my theme directory and renamed accordingly (views-exposed-form--[view name].tpl.php). I did not edit the script in the template. (My reference: http://timonweb.com/how-display-views-exposed-filter-block-and-theme-it)
Then in my views-view--[view name].tpl.php, I added the following script:
I don't really understand what view-dom-id- does even after reading a bunch of articles...but I added in as a div after reading the following post: https://www.drupal.org/node/690748. If I don't have it in the views template, then the filter doesn't work.
DEFAULT SCRIPT IN views-exposed-form--[view name].tpl.php
I've spent 2 days trying to debug, so any guidance would be greatly appreciated!!
Thank you for taking the time to read
UPDATE: I realized my issue -- In my Views template, I needed to place my divs outside of the
if ($rows):
:-pComment #24
couloir007 CreditAttribution: couloir007 commentedHere is something I did. It's not not remembering, so I need to reset the input.