The Calendar module is based on separate start and end date fields. Date range fields are not properly supported. There is the promise to fix all this in the 2.x release but there is no release yet. The changes suggested in this branch try to fix daterange support for 1.x.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | support_date_range_field-3240209-11.patch | 674 bytes | jonasanne |
| #3 | support_date_range_field-3240209-3.patch | 4.83 KB | zero2one |
| #2 | support_date_range_field-3240209-2.patch | 6.05 KB | zero2one |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
zero2one commentedThe provided patch replaces the outdated patches from issue #2699477
Comment #3
zero2one commentedThe previous patch was also trying to fix the rendering of multiple-day options (there is a bug in that functionality to). The new patch only fixes support for date range fields.
Comment #4
zero2one commentedComment #7
gilmordHi, zero2one
please check the MR I opened in the fork, without this change even with your patch I was still facing issues - no events on calendar when using date-range field.
Can you also replace your patch file with a fork and merge request and include the change I did?
Thanks!
Comment #8
imclean commentedCalendar checks the ID to determine the type of handler.
IDs can change, for example when a module extends a handler to implement additional functions. It might be safer to check whether the object or its parent is a specific class. is_a() might help.
Comment #10
joelpittetWhile doing #3522299: Audit and remove obsolete @todo comments and dead code I really questioned the value of this check. Didn't change it there but it might need thought.
@gilmord & @zero2one could one of your (or any others) give me some some minimum steps to reproduce the bug/feature this MR or patches are meant to do?
@gilmord is
views_daterange_filters_daterangesome contrib module you are trying to resolve along with this? Your comment is not clear but that is not a plugin from core so maybe it's meant to support this https://www.drupal.org/project/views_daterange_filtersComment #11
jonasanne commentedUploading diff of MR to use as patch
Comment #12
joelpittet@jonasanne can you explain what the patch is actually doing?
Comment #13
baluertlComment #14
baluertlThis is indeed an awkward situation: several community members have made efforts (opening a ticket, creating a patch, converting it to an MR, suggesting improvements, etc.) in the hope of contributing to the good of all. However, missing crucial information (reproduction steps), all the puzzle pieces are still spread out and hard to put together from this timeline of years. I just stumbled upon this ticket while updating the packages of external dependencies for one of our client projects, and even digging back our repository history to the initial commit did not reveal any useful information. The journey of our project has started on 13 Sept 2018 with including one of the patches from the good ol’ #2699477: Steps towards handling end dates in Calendar 8 ticket – recently rightfully closed as outdated by maintainer @joelpittet.
Some years later, the
https://www.drupal.org/files/issues/2018-04-06/calendar-date_range-2699477-71.patchURL was simply replaced with
without any proper reasoning or even describing what bug or issue is intented to resolve. Having all that said, I dared to toggle its status to “Needs information”. At this very moment, we lack the understanding of why the suggested code changes are necessary. Therefore, the requirements of “Needs review” status is obviously not fulfilled.