Hello,

I would like to report this bug on Views 6.x-3.x-dev (Last updated: February 15, 2010 - 09:17)

I created a user view type, added fields and exposed filters, set exposed filter as a block, and include reset button. The Reset button works fine when AJAX is disabled, but when enabled the Reset button looks to load but the exposed form block filters do not get reset.

I found this post where I believe it was added but was not very clear towards the end.
#99370: Add a 'reset' button to exposed filters

Thanks for all the great work with Views! Its such a great module.

Regards

CommentFileSizeAuthor
#12 720054.patch4.92 KBdawehner
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

So you have the exposed form in a block?

For me the reset button worked on a non-block placement. Ajax was enabled. Then i added the exposed-form block, and testet it. It seems to be, that the ajax does not work there.

YK85’s picture

YK85 CreditAttribution: YK85 commented
Title: Reset filters not working when AJAX enabled » Reset not working with AJAX enabled when Exposed form in block

Hi dereine,

Thanks for the quick reply. I have re-tested and found that Reset works with AJAX enabled if Exposed form is not in a block.
I have changed the title to reflect the issue. Thanks!

Reset with AJAX enabled (Exposed form in block:NO) works
Reset with AJAX enabled (Exposed form in block:YES) does not work

Regards

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

But this is still a bug, right? I'm not sure whether it makes sense to enable ajax in a block.

YK85’s picture

YK85 CreditAttribution: YK85 commented

sorry for getting back to you late.

I did not know that a view with the exposed filter as a block should not have ajax enabled. Is this the case?

I have a page view with the exposed filter as a block shown in the left region.
I would like to use AJAX on the view as the loading looks nice for the end-user.

Thank you

esmerel’s picture

esmerel CreditAttribution: esmerel commented
Status: Active » Closed (won't fix)

This is likely better suited as something added on to views for sites that really need it. It's got big potential performance impacts and probably isn't something best suited for core views functionality.

merlinofchaos’s picture

merlinofchaos CreditAttribution: merlinofchaos commented
Status: Closed (won't fix) » Active

Actually I think we can call this a bug. This should be something that can be made to work; the ajax response needs to be a little smarter to handle the exposed form in a block case, but we have all of the information so I *think* this can be fixed.

Letharion’s picture

Letharion CreditAttribution: Letharion commented
Assigned: Unassigned » merlinofchaos
Letharion’s picture

Letharion CreditAttribution: Letharion commented
Assigned: merlinofchaos » Unassigned

I was mainly touching this issue because it's old and unassigned. Doesn't necessarily need to be assigned to Merlin though, so I'm reverting that.

Letharion’s picture

Letharion CreditAttribution: Letharion commented
Assigned: Unassigned » merlinofchaos

I seem to be confused today.

merlinofchaos’s picture

merlinofchaos CreditAttribution: merlinofchaos commented
Assigned: merlinofchaos » Unassigned

Yeah, there's no reason to assign this to me. Not sure when it'll get worked on.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

I'm wondering whether it makes sense that views implements hook_ajax_data_alter for itself?

There check whether the current request comes from the request button and if yes, reset the form values.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented
Status: Active » Needs work
FileSize
720054.patch4.92 KB

I'm quite confused here. There is the ajax response coming in, there exposed_form::reset_form() is called but then in the alter hook the view seems to be unchanged again.

Oh yes the actual form submit triggers another request to handle the data. Does someone has an idea how to get the context in?
Would form_state for example work/make_sense?

vlooivlerke’s picture

vlooivlerke CreditAttribution: vlooivlerke commented

Wow this patch looks impressive (I patched by hand) but it does not work :(
I patched it against the latest 3xdev for D6

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody commented
Issue summary: View changes

Here you can find a solution that replaces the default reset functionality by an AJAX version. It doesn't have the problems described above. http://julian.pustkuchen.com/node/659

I hope it helps some of you as a workaround (but it is for Drupal 7 and Views 3) which has similar problems.

julian.montagna’s picture

julian.montagna CreditAttribution: julian.montagna commented

Awesome Anybody. Works great!!
You saved my day!! Thanks a lot!!

SunnyGambino’s picture

SunnyGambino CreditAttribution: SunnyGambino commented

Thanks Anybody!
I confirm, it is working! :)

Chris Matthews’s picture

Chris Matthews CreditAttribution: Chris Matthews as a volunteer commented
Status: Needs work » Closed (outdated)

The Drupal 6 branch is no longer supported, please check with the D6LTS project if you need further support. For more information as to why this issue was closed, please see issue #3030347: Plan to clean process issue queue