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

udane’s picture

I have the same problem.
Any solution?
Thanks.

foredoc’s picture

Have no idea how to solve this

infojunkie’s picture

Version: 6.x-1.0-beta1 » 6.x-1.x-dev

Can 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?

udane’s picture

I 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.

eL’s picture

Title: Auto-submit / Rest do not work with views display tab module » Auto-submit / Rest do not work with views display tab module and with quick tabs

Same problem with Quick tabs module. Auto submit work only for first tab...

infojunkie’s picture

Re #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?

eL’s picture

Re #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?

infojunkie’s picture

Ajax in View, no Ajax in QT - that's what worked for me.

Sawascwoolf’s picture

no 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

infojunkie’s picture

Status: Active » Fixed

Setting as fixed with the solution in #8 and confirmed in #9.

nyah’s picture

The 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?

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

devkinetic’s picture

Status: Closed (fixed) » Active

Reopening 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.vfas is 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.vfas to the exposed_form_id of "page_1". Now when the second view "page_2" is loaded, Drupal.settings.vfas is 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.

devkinetic’s picture

I 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:

drupal_add_js(array('vfas' => array($form['#id'] => array('exceptions' => implode(',', $exceptions)))), 'setting');

And replace it with this:

foreach ($form['#parameters'][1]['view']->display as $display) {
      $filter_id = 'views-exposed-form-' . str_replace('_','-',$form['#parameters'][1]['view']->name) . '-' . str_replace('_','-',$display->id);
      drupal_add_js(array('vfas' => array($filter_id => array('exceptions' => implode(',', $exceptions)))), 'setting');    
    }

With the proper filter form ids passed, the javascript needs no modifications.

infojunkie’s picture

@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.

devkinetic’s picture

The 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.