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...
Comment | File | Size | Author |
---|---|---|---|
#24 | 2185449-fullcalendar-ajax-fix-24.patch | 1.13 KB | Jorrit |
#17 | ajax_date_format-2185449-17.patch | 2.75 KB | cathsens |
#3 | ajax_date_format-2185449-4.patch | 2.01 KB | bkosborne |
Comments
Comment #1
bkosborneOk, narrowed this down a bit. In
fullcalendar.views.inc
, the module hooks intohook_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.
Comment #2
bkosborneConfirmed 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.
Comment #3
bkosborneWent 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.
Comment #4
bkosborneSort 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.
Comment #5
pjcdawkins CreditAttribution: pjcdawkins commented#3 fixes it for me.
Comment #6
pnavarro CreditAttribution: pnavarro commented#3 fixes it for me to, thx a lot!
Comment #7
seantwalsh#3 fixes it for me too!
Comment #8
dniemeye CreditAttribution: dniemeye commentedHas 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.
Comment #9
dniemeye CreditAttribution: dniemeye commentedSo 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?
Comment #10
seantwalsh@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.
Comment #11
robcarrI had a whitespace error on the patch at #3. Attached a re-roll
Comment #12
Itangalo CreditAttribution: Itangalo commentedPatch #11 works fine for me, too. Time to commit?
Comment #13
manuelBS CreditAttribution: manuelBS commentedThis patch also works for me and a commit would be really nice.
Comment #14
tim.plunkettCommitted. Thanks @bkosborne and @arrrgh, as well as those who tested.
Comment #17
cathsens CreditAttribution: cathsens as a volunteer commentedThe 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.
Comment #18
izmeez CreditAttribution: izmeez commented@cathsens The new patch in #17 appears to not change the previous patch but adds a new fix
Would it not be better to open a new issue with just this change?
Thanks.
Comment #19
cathsens CreditAttribution: cathsens as a volunteer commentedHi @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.
Comment #20
izmeez CreditAttribution: izmeez commented@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.
Comment #21
nimoatwoodwayin case someone else has the same problem and uses jquery > 1.8. Ajax doesnt work!
check https://www.drupal.org/node/2325549
Comment #22
Tabestan CreditAttribution: Tabestan commentedBoth patched failed for me, are they supposed to be applied against 2.x-dev?
Comment #23
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedthe patch in 17 fails because the previous patch was already committed.
#18 is a good suggestion
Comment #24
Jorrit CreditAttribution: Jorrit at nCode for DOM Digital Online Media GmbH commentedThis is patch 18 that applies to the latest -dev.