Contextual filters break Ajax views: Ajax date arguments should be replaced with hidden exposed filters

For ajax'd exposed filters, this might work after #971034: Add Option To Load Events Via Ajax.

For filters that trigger a page request, we might be able to track the active view mode, and shove it back in for #1206518: Call a specific calendar view through the URL to pick up on...

When using Ajax loading, exposed filters do not work.
Also, using an exposed filter rebuilds the calendar, setting it back to it's default date and view.

tagging

This doesn't *need* to be in before beta.

Part of this is fixed by #1359798: Clean urls off break all Ajax views.

But the real issue is that views_ajax runs the view once, and then because Drupal.fullcalendar.navigate is already set to true, the query is run again without the filter.

One option is to prevent the views_ajax query from running and then intercepting the filter value.
The other is to hijack the views_ajax query to add our dates, and somehow override Drupal.fullcalendar.navigate.

So now reading what you put I may be way off on this but I'll post it here anyway. Works for date not for mode.

In fullcalendar.fullcalendar.js line 49

       var prev_date, next_date, date_argument, arguments, fetch_url;

        if (!settings.loaded) {
          $('.fullcalendar', calendar).fullCalendar('gotoDate', settings.previous_date.year, settings.previous_date.month, settings.previous_date.day);
        }

        current_date =  $('.fullcalendar', calendar).fullCalendar('getDate');

        if (typeof settings.previous_date === 'undefined') {
          settings.previous_date = {};
        }
        settings.prev_date.year = parseInt($.fullCalendar.formatDate(current_date, 'yyyy'));
        month = parseInt($.fullCalendar.formatDate(current_date, 'M'));
        settings.prev_date.month = month - 1;
        settings.prev_date.day = parseInt($.fullCalendar.formatDate(current_date, 'dd'));

in fullcalendar.view.js line 40

      settings.fullcalendar[dom_id].loaded = false;
      // Use .once() to protect against extra AJAX calls from Colorbox.
      $('.fullcalendar', calendar).once().fullCalendar(options);
      settings.fullcalendar[dom_id].loaded = true;

Here is a patch. I've only tested this with ajax version.

This patch takes care of mode. This is ajax only.

This one is more reliable. It fixes an issue where it wouldn't return to the correct date in day/week mode.

So this patch is just about not losing your place in the calendar after you've paged around?
Because it still doesn't let the exposed filter actually *do* anything.

I've exposed Content: Nid, to just filter down the set to one event.
Without the patch, going forward or back a couple months and applying the filter takes me back to the initial date, all events shown.
With the patch, the calendar reloads at the same month when I click the filter, but all events are still shown.

And what's more, the query is run twice. Once with the exposed filter as the only argument, and once with the date as the only argument. It should run the query once, with both arguments.

So this solves the other half of the problem, the part about actually using the filters. It also, for some reason, seems to break the patch in #9.

Also, there is a Views bug that helped break all of this, see #1360336: views_ajax() can't find certain handlers.

It's now calling attach: twice. I saw a few issues in views that talked about this, but I haven't seen a real solution.

Here is a combined patch that seems to be working.

This patch works in terms of keeping the display on the right month. But it doesn't seem to run the query for the new month, but instead whatever the initial month was.

For example, I load the calendar with ?month=8, page through to December, apply a filter, and December is shown, but with no events.

We're going to have to abandon the use of arguments altogether and use hidden exposed filters.

"Hidden" just means we should try '#access' => FALSE. If that doesn't work, display: none; :)

Also: #1367304: Using OR in filters breaks contextual filters

Postponing on #1367304: Using OR in filters breaks contextual filters :(

Yay!

For better discoverability in the queue.

Finally had a spare day to work on this.

This removes all of the custom AJAX callback and the arguments, in favor of using exposed filters and just triggering the ajax view handler with JS.

It might be a little slower, but it actually works. It can't be a performance regression if the old one never actually worked...

Well... it kinda works but...

Is it intentional to show the apply button? And is it intentional you have to click apply on each month you visit?
That is kinda strange...

+++ b/js/fullcalendar.fullcalendar.jsundefined
@@ -32,39 +32,23 @@ Drupal.fullcalendar.plugins.fullcalendar = {
+              $('#edit-submit-fullcalendar', fullcalendar.$calendar).eq(0).click();

Awesome this only works with views that are named "fullcalendar". ;)
So that is the first bug.

And I tried to hide the apply button just for testing but that also hides the ajax throbber.
We need to add the ajax throbber to the calendar in stead of the filter if that is possible.

ps: I don't see any performance regression at all on my test sites (tiny datasets). And I rly rly rly rly love this approach :D. Gone custom code!

Things to do:

1. hide the apply button but only when there are no other exposed filters
2. still show the throbber


3. address the submit button generically

I know how I'll do 1 and 3. We'll see about 2.

Okay, here's everything but the throbber.

Okay, now it still works for all views.

Still no throbber.

Hmm now that it's working so nicely I spot visual bugs faster:

1) Switching days does trigger an ajax refresh after some time but no events are loaded.
2) When using an aditional exposed filter and you're in week mode for example.
==> Go to the first week of this month
==> filter on something
==> after ajax refresh we are back in the current week and not the week we were looking at

If possible this needs a goto(date) somewhere...

Other tests:
------------
- google calendar works
- standard calendar works
- adding a new filter works

Changed some of the handling around.

There's still something really weird going on, I think code is getting called twice. Navigating feels nowhere near as smooth as it used to be :(

Currently, clicking next/prev switches the day/week/month, which triggers a custom ajax call to the view, which only returns the events themselves, which we then process.

With this patch, clicking next/prev switches the day/week/month, which triggers the submit button for the exposed filters, which rebuilds the entire view from scratch, removes the old one that already switched to the new day/month/week.

That's not going to work.

I'll have to look at triggering the submit differently, intercepting it in a hook, still only returning the events, and processing them.

Still needs some code docs, but I *think* this works?

maybe...

1) dragging in "all day" does'n't work, after a refresh the events are back where they cam from
(maybe that was alrdy broken)
2) add a date on "jan 1", "jan 15", "jan 30":

- calendar loads in january, everything is ok
- switch to december, everything is ok
- switch to january again, "jan 1" is instantly visible but 15 en 30 show after loading

3) Before a cache clear I got lots of ajax errors and after a cache clear I get lots of ajax errors in the views UI. For example I can't open the settings anymore. Saving a google caledar field goes "kabooom".

Maybe this is cause by the missing throbber:

When moving fast between january and february, my events on january suddenly dissapear. But when I go to december and go back to january they are back again!

Ow and even better!

Clicking between january and december (setup like in #31) rly fast I sometimes get the following result:

- I'm in january
- January 1, 15 and 30 are loaded
- Go to december (rly quickly)
- january 1 is loaded
- Go to january again (quicker :p)
- First I see 1, 15, 30 (instantly) and than 15 and 30 dissapear ==> WTF o_O

I'm guessing this is all related :)

Okay, this prevents you from clicking next month until the current one is done loading.

Not ideal, but I don't think it's possible otherwise.

WAAAAY better. You still broke the fullcalendat settings page somehow...

I'm in over my head a bit here, but to solve #34, should you not abort the previous AJAX request (with xhr.abort()) when a new request is made, i.e. when the user clicks for the next month? Or are you doing that already?

@pjcdawkins, I thought about that, but unfortunately Drupal.ajax provides no way to access that:
http://drupalcode.org/project/drupal.git/blob/refs/heads/7.x:/misc/ajax....

This element is part of a form, so it uses the third-party ajaxSubmit plugin which bypasses xhr altogether, and even if it weren't a form, it would need to capture the return value of $.ajax somewhere.

@aspilicious not sure what you mean. Still works for me.

:( view is hosed again on my test site. If I test a clean upgrade it works again. =(
It's so strange this always happens to me when trying multiple ajax patches...

Uncaught TypeError: Cannot read property 'form' of undefined
Drupal.ajaxajax.js:137
Drupal.fullcalendar.fullcalendar.submitInitpage:123
Drupal.fullcalendar.plugins.fullcalendar.optionspage:11
Drupal.fullcalendar.fullcalendarpage:30
Drupal.behaviors.fullcalendar.attachpage:15
Drupal.attachBehaviorsdrupal.js:55
b.extend.eachjquery.js:33
Drupal.attachBehaviorsdrupal.js:53
Drupal.ajax.commands.insertajax.js:542
Drupal.ajax.successajax.js:400
Drupal.ajax.ajax.options.successajax.js:164
b.fn.ajaxSubmit.a.successjquery.form.js:12
c.extend.handleSuccessjquery.js:143
c.extend.ajax.w.onreadystatechange

Hmm I have another site testing fieldgroups. And something weird is happening there...

I switch (slowly ;) ) to december with no events in january. The december events are shown for a second and than they are gone again :(

So, I got the same results on two fresh installs of D7.

When I create the View and go to add a date field, I get a screen full of endless strings of text.

If I hit refresh on the page or go back - the date field appears, but I can't seem to edit it or the settings for fullcalendar in the view. Upon checking Google's Dtools, I get the error message "Uncaught Type Error: Cannot Read property 'form' of undefined" this is ajax.js line 137, the following block

  // If there isn't a form, jQuery.ajax() will be used instead, allowing us to
  // bind Ajax to links as well.
  if (this.element.form) {
    this.form = $(this.element.form);
  }

I tried it on another test site with no problem. A clean install of beta2 is tomorrow.

This fixes a multitude of other problems, mostly related to non-month views.
Code still needs comments.

I'm not sure what I'm supposed to be able to do with that patch, but with a cursory test, it breaks my fullcalendar's taxonomy-based colour-coding, and while my AJAXed exposed filter does return a calendar (unlike before the patch), it doesn't actually filter results.

I get a JavaScript error which occurs after using the exposed filter (screenshot attached):
this.$submit is undefined

No watchdog errors.

This still needs work per #40 and #42, but it's rerolled with the following patches applied first:
#1429466: Remove Colorbox options when disabled
#1428536: Pass along the JS settings to plugins to simplify the API
#1427664: Don't use hook_fullcalendar_options_submit when not appropriate
#1429458: Views aren't set up properly from wizard

My JavaScript error is slightly different with the patch in #43, but the calendar is still completely broken.

I know this doesn't work, it's the same as the last patch, just rerolled to not fall too far behind.
I hope to have time for this soon.

This should fix the problem, it works for me.

Doesn't seems to work here. I only get a contextual filter with the dates. And the patch ndidn't applied cleanly on latest dev code

Any updates on this? Running into the same issue. When I choose an exposed option the calendar disappears and no matter what option I choose after that I get nothing. I haven't tried any of these patches, but it looks as if the issue isn't solved.

Any updates here?

I revisited this, finally.

It still doesn't take affect for the initial application of exposed filters, but the rest seems to work.

I'll work more on that now.

Okay, here's an updated patch, this one works in all of the cases I tested (which is not everything).

http://drupalcode.org/project/fullcalendar.git/commit/44ec5d1