Active
Project:
Views Hacks
Version:
6.x-1.x-dev
Component:
Views Filters Auto-submit
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
15 Nov 2010 at 18:46 UTC
Updated:
16 Apr 2012 at 16:30 UTC
Hi,
I am currently use views hacks and views display tabs. Seems to me that the auto-submit/rest only work for the first tab generated by views display tabs.
Any idea how to fix this?
Thanks
Hang
Comments
Comment #1
udane commentedI have the same problem.
Any solution?
Thanks.
Comment #2
foredoc commentedHave no idea how to solve this
Comment #3
infojunkieCan you please try with the latest dev? Some fixes went in that could solve this.
If it doesn't please explain how to setup a view to reproduce this. Is "views display tabs" a module?
Comment #4
udane commentedI have tried with the latest dev and it doesn't work.
My view has 3 displays, they inherit an exposed filter and they are shown in 3 tabs using the "views display tabs" module. In the first tab the auto submit works, but not in the others. In the other tabs the user has to use the submit button.
Thanks.
Comment #5
eL commentedSame problem with Quick tabs module. Auto submit work only for first tab...
Comment #6
infojunkieRe #5: It seems that a non-Ajax view with exposed filters does not behave correctly with QuickTabs: applying the exposed filters form redirects to the view page (without auto-submit). Can you confirm this?
With an Ajax-enabled view, I was able to auto-submit and reset the view on the second tab. Can you confirm this?
Comment #7
eL commentedRe #6: Turned on Ajax in the View, but autosubmit still only in first tab.
Do you think AJAX in Views, or AJAX in QuickTabs settings?
Comment #8
infojunkieAjax in View, no Ajax in QT - that's what worked for me.
Comment #9
Sawascwoolf commentedno ajax in QT,
Ajax in Views
updatet from 6.x-1.0-beta1 to 6.x-1.x-dev
solved this problem for me, now auto submit works in 4 Tabs
Comment #10
infojunkieSetting as fixed with the solution in #8 and confirmed in #9.
Comment #11
nyah commentedThe original post was regarding the 'Views Display Tabs' module - http://drupal.org/project/viewsdisplaytabs - so I'm not sure that this issue is fixed.
I think comments #1, #2 and #4 were also referring to the 'Views Display Tabs' module. I'm having the same problem as described in #4. Any solution for this?
Comment #13
devkinetic commentedReopening as this issue is still active with the views display tabs module, as nyah also expressed.
I believe the solution that worked for quicktabs is not a solution but a workaround. The issue is when the view is loaded via ajax that form_alter and relevant javascript is not triggered.
I believe that the form alter is being called because whenever I try to debug it, I can no longer load the tabbed view. I believe the javascript is not being executed because
Drupal.settings.vfasis not being updated to reflect the ID of the exposed filter on the tabbed view, explained below...For example my view is comprised of "page_1" & "page_2". Using views display tabs, I load "page_1" as active and "page_2" will be called via ajax when clicked. The form alter runs on "page_1", and sets
Drupal.settings.vfasto the exposed_form_id of "page_1". Now when the second view "page_2" is loaded,Drupal.settings.vfasis not updated with the exposed_form_id of "page_2". If you jump into the javascript, right on line 7:$.each(Drupal.settings.vfas, function(form_id, settings) {Since that settings is not updated, even though the behavior may be triggered, the javascript will not be applied as the exposed_form_id value doesn't match.
Comment #14
devkinetic commentedI found a workaround for this. This would need a bit more love before being rolled into the module, but what I did is I decided to retrieve all of the displays for the enabled view, and add them to
Drupal.settings.vfas.In views_filters_autosubmit.module, remove this line:
And replace it with this:
With the proper filter form ids passed, the javascript needs no modifications.
Comment #15
infojunkie@devkinetic thanks for the fix. What kind of more "love" would be needed to turn this into a regular patch? I assume the form IDs you are creating are valid as far as FAPI is concerned.
Comment #16
devkinetic commentedThe issue is definitely fixed now, but to bring it full circle some of the module settings would have to be modified to match the displays within each view, rather than the view in its entirety.
In my example, I'm grabbing the view that has been marked in the settings for auto-submit functionality. But now that we are dealing with each display in the view independently (as opposed to the entire view itself), the settings page should follow suit and let us enable/disable each display within each view.
My modified code would have to be further modified to validate against those settings, which would complete the patch.
Anyone would be able to easily make these changes, I just have a deadline in 5 days, so I cannot.