Turning AJAX on seems to break something with the module - but I can't quite figure it out yet.

I created a content type with a single date field (non repeating). I didn't add any content though. I created a view that displays data from this content type, and added the date field to the list of fields. The style is set to FullCalendar with all the default options. I turn on AJAX.

When I view the calendar, it displays the month view of January. When I switch to Feb, everything seems fine, but when refreshing the page two errors appear:

The value input for field Start date is invalid:
The value 2014-01-26 does not match the expected format.
The value input for field End date is invalid:
The value 2014-03-09 does not match the expected format.

Now, if I actually add content that uses that date field (like for January 31st), it appears properly on the initial load of the view. When I change to Feb, it appears in the Feb view (since the end of Jan is displayed on top) but disappears VERY quickly. Reloading the page reveals the same error messages above.

Turning AJAX off in the view resolves the issue.

I'm spending time today trying to dig into this - but it's a bit daunting since it seems like I need to get deep into Views, Date, and FullCalendar to see what's happening. Any help is appreciated.

Note that I did find someone else with the same problem who posted on Drupal stack exchange, but he removed the post. Here is the cached version: http://webcache.googleusercontent.com/search?q=cache:xl45jCHMNtMJ:drupal...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bkosborne’s picture

Ok, narrowed this down a bit. In fullcalendar.views.inc, the module hooks into hook_views_pre_view and creates a "between" argument for the date field (exposed, but hidden in the UI), providing a default start and end date.

It always provides the default dates the format "Y-m-d". However, once the javascript in fullcalendar.ajax.js runs, it replaces these values with a different format, which is contributing to the issues.

The date field has an expected format and obviously the text input that is submit with it needs to match up. I was temporarily able to fix mine by changing the format that the JS file uses for the dates to match what the exposed date field is expecting.

I should be able to come up w/ a patch for a real fix.

bkosborne’s picture

Confirmed that the real issue is that fullcalendar.ajax.js ALWAYAS uses the date format of "Y-m-d" (represented in fullcalendar notation as "yyyy-MM-dd") when filling in dates for the exposed filter during month transitions.

The format that the exposed filter fields are expecting is completely determinate on what the site has set for "date_format_short" (in the standard Drupal date settings). The granularity for the date fields is set to "day", so it takes whatever format is in short and limits it to show just year, month, day (which is probably how short is setup anyway on most sites).

So the problem is that unless your site's settings for "date_format_short" are Y-m-d (to match what fullcalendar.ajax.js creates dates as), things break, since Date is expecting a different format.

Can't think of a silver bullet to fix yet. There's no way to FORCE the exposed date fields to expect a specific format of date input, which would be ideal (since we could just match it with what's in our JS file). Two possibilities:

#1 - Set the date format that the date field is expecting in the DOM somewhere and have the JS parse it so it knows how to construct its dates. The problem here is that we need to convert the format strings from Drupal-speak (PHP) to FullCalendar-speak (http://arshaw.com/fullcalendar/docs/utilities/formatDate/)

#2 - Change the exposed form to select drop downs instead - which may be easier to work with w/o creating format conversion code.

bkosborne’s picture

Status: Active » Needs review
FileSize
2.01 KB

Went with #2 which was pretty simple. Using the select inputs instead of text inputs eliminates any weirdness that can pop up due to different date formats.

bkosborne’s picture

Sort of related discussion about how the date format of the text fields for exposed date filters are handled: #1409120: Date format in views exposed filter does not respect configured format

Also note that to resolve this issue it's also possible to form_alter the exposed form and manually set the date format to what you want, but the patched solution works just as well and is a bit cleaner IMO.

pjcdawkins’s picture

Status: Needs review » Reviewed & tested by the community

#3 fixes it for me.

pnavarro’s picture

#3 fixes it for me to, thx a lot!

seantwalsh’s picture

#3 fixes it for me too!

dniemeye’s picture

Has anyone discovered a total fix for this? I'm not using Ajax but I have the exact same symptoms as described above when not using ajax. I've tried ajax and get the same problem. So it doesn't seem to be ajax that's the problme. I'm using FullCalendar with D7. If go forward one month and then go back to this month, events don't show then if you refresh the event shows up but errors, in my case multiple errors that seem to relate to ends and middle dates of months, but almost seems random.

"The value input for field Start date is invalid:
The value 2014-06-01 does not match the expected format.
The value input for field End date is invalid:
The value 2014-07-16 does not match the expected format."

Since I'm not using Ajax I don't think i need fix #3. I've tried everything, changing the way the site handles time zones, short time format (tried several including some that seem to use yyyy-mm-dd) and still same problem.

dniemeye’s picture

So on the ajax patch: Do you save it exactly as it is or what? Where do you put it? Do you insert it into another file for ajax?

seantwalsh’s picture

@dniemeye, the documentation for applying patches can be found at https://drupal.org/patch/apply. You may also want to confirm your settings in the Fullcalendar View you've setup. On mine I'm explicitly defining what fields I'm using under Format > Settings.

robcarr’s picture

I had a whitespace error on the patch at #3. Attached a re-roll

Itangalo’s picture

Patch #11 works fine for me, too. Time to commit?

manuelBS’s picture

This patch also works for me and a commit would be really nice.

tim.plunkett’s picture

Status: Reviewed & tested by the community » Fixed

Committed. Thanks @bkosborne and @arrrgh, as well as those who tested.

  • tim.plunkett committed 2ab7b6b on 7.x-2.x
    Issue #2185449 by bkosborne, arrrgh: Fixed Using AJAX results in errors...

Status: Fixed » Closed (fixed)

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

cathsens’s picture

Status: Closed (fixed) » Needs review
FileSize
2.75 KB

The previous patch causes an error in reports : "Notice: Undefined index: date in fullcalendar_views_pre_view() (line 112 of .../fullcalendar/includes/views/fullcalendar.views.inc)."
I corrected it in a new patch.

izmeez’s picture

@cathsens The new patch in #17 appears to not change the previous patch but adds a new fix

@@ -109,7 +109,10 @@
     // Add an exposed filter for the date field.
     $field_value_id = $field->real_field . str_replace($field->field, '', $field_id);
     if (isset($exposed_input[$field_value_id])) {
-      $timestamp = (strtotime($exposed_input[$field_value_id]['min']['date']) + strtotime($exposed_input[$field_value_id]['max']['date'])) / 2;
+      $exposed = $exposed_input[$field_value_id];
+      $min = mktime(0, 0, 0, $exposed['min']['month'], $exposed['min']['day'],$exposed['min']['year']);
+      $max = mktime(0, 0, 0, $exposed['max']['month'], $exposed['max']['day'],$exposed['max']['year']);
+      $timestamp = ($min + $max) / 2;
       $min = date('Y-m', $timestamp);
       $max = date('Y-m', strtotime($min . ' +1 month'));

Would it not be better to open a new issue with just this change?

Thanks.

cathsens’s picture

Hi @izmeez,
The new patch fix an issue related to the previous version, not to the module. That's why I published a new version of the patch.

izmeez’s picture

@cathsens Maybe you can provide an interdiff to show the difference between the patch that was committed and your patch. Just from a quick scan of the two the differences I saw were as in comment #18. I could not see any changes in your patch to the changes in the patch that was committed.

Thanks.

nimoatwoodway’s picture

in case someone else has the same problem and uses jquery > 1.8. Ajax doesnt work!

check https://www.drupal.org/node/2325549

Tabestan’s picture

Both patched failed for me, are they supposed to be applied against 2.x-dev?

SocialNicheGuru’s picture

the patch in 17 fails because the previous patch was already committed.

#18 is a good suggestion

Jorrit’s picture

This is patch 18 that applies to the latest -dev.