- 26 Nov, 2013 1 commit
-
-
Robert Rollins authored
The Date Repeat module’s date_repeat_build_dates() function does not support RDATEs and EXDATEs defined as separate properties, as well as being a bit buggy in other ways. So I copy-pasta’d it and made the necessary fixes. I wanted to add support for EXRULEs, but it’s more complicated than I expected. So since no one has actually asked for it, I left it as a TODO.
-
- 18 Nov, 2013 2 commits
-
-
Robert Rollins authored
-
Robert Rollins authored
Date iCal 3's use of the Libraries APIs was slightly less awful than 2's, but it would still fail to properly detect an incorrectly installed iCalcreator.
-
- 12 Nov, 2013 1 commit
-
-
Robert Rollins authored
This is a forward-port of the fix that I just submitted to the 2.x branch.
-
- 11 Nov, 2013 2 commits
-
-
Robert Rollins authored
-
Robert Rollins authored
Because OSX uses a case-insensitive file system, git didn't pick up the change I made when I re-wrote the parser. In retrospect, I probably should have chosen a totally new name for the feeds parser, but the existing filename *was* the most appropriate name for the new class, just with different capitalization.
-
- 05 Nov, 2013 2 commits
-
-
Robert Rollins authored
-
Robert Rollins authored
As jakemonO pointed out, the Calendar will not display All Day events which have no end date value, which means that Date iCal's method of leaving off the end date for single-day All Day events was a really bad idea. Fortuantely, setting the end date to the same day as the start date makes the date node display correctly for single- day events, which was the reason that the end date was being left off in the first place. This means that every All Day event can simply have it's end date rewound by one day, and all is well in both the node display and the Calendar.
-
- 04 Nov, 2013 1 commit
-
-
Robert Rollins authored
User oskar_calvo discovered that if you update Date iCal from 1.x, but don't also install the Libraries module, you'll get a fatal error when Date iCal attempts to check for the iCalcreator library, because the libraries_detect() function doesn't exist. Now, you'll instead see an error in the site requirements.
-
- 29 Oct, 2013 1 commit
-
-
Robert Rollins authored
-
- 28 Oct, 2013 4 commits
-
-
Robert Rollins authored
-
Robert Rollins authored
-
Robert Rollins authored
Rather than defaulting an an illegal value, the Fields plugin's settings form now offers "First populated Date field" as the default option for "Date field". Using this option will tell Date iCal to look through all the fields in the View until it finds a populated Date field, and use that field. So, if there are two Date fields specified in the view's FIELDS setting, and at runtime the value of the first one is empty (e.g. because the node doesn't use that field), then the second Date field's value will be used.
-
Robert Rollins authored
The update hook now also checks for importers which are set to the new parser, but still have un-capitalized source keys. This will help users who forget to run the database update before manually fixing the missing DateIcalIcalcreatorParser warning.
-
- 25 Oct, 2013 1 commit
-
-
Robert Rollins authored
This commit adds the migration code that converts all Feeds Importers which used the DateIcalIcalcreatorParser plugin to use DateiCalFeedsImporter instead. The old classes have been removed.
-
- 24 Oct, 2013 1 commit
-
-
Robert Rollins authored
Renamed hook_date_ical_import_calendar_alter to hook_date_ical_import_vcalendar_alter, to match the export hook. Also did some minor refactoring and comment editing. Date iCal 3.0 is nearing completion! The only major task remaining is to write the migration code.
-
- 22 Oct, 2013 1 commit
-
-
Robert Rollins authored
iCal feeds are now parsed in batches of 50 (by default). The Date parser code has been significantly improved, removing the old limitation of needing to parse DTSTART first, and also covering more edge cases and error conditions.
-
- 21 Oct, 2013 1 commit
-
-
Robert Rollins authored
I hadn't yet tested the RRULE import code when I first pushed Date iCal 3.x-dev, but now I have. It's much more robust than it was in 2.x. In addition, I moved the parsing class out of DateiCalFeedsParser.inc and into libaries/ParserVcalendar.inc, which is like how Feeds' own CSV parser is set up.
-
- 18 Oct, 2013 1 commit
-
-
Robert Rollins authored
This new version is still in a state of partial completeness. You may need to do some manual fixing to get it working, due to a change I made in the classes offered by this module. Try 'drush cc registry' if 'drush cc all' fails. Please note that ALL of the hooks exposed by Date iCal have changed. They do essentially the same things they used to do, but they're named differently. The big change is that the Feeds plugin has been completely re-written to conform to the Feeds APIs. It's now much more resilient and powerful. Feeds Tamper will now work, and is in fact the prescribed way to alter data, since I removed several alter hooks.
-
- 17 Oct, 2013 1 commit
-
-
Robert Rollins authored
Some ical feed readers will erroneously take the DTSTAMP field into consideration when comparing a new download to a previous one, and end up treating all events as having been updated, because their DTSTAMP field is different. This new option lets you get around those buggy readers. I also added the CREATED field, which was embarassingly missing until now.
-
- 16 Oct, 2013 1 commit
-
-
Robert Rollins authored
LAST-MODIFIED was only being included if $entity->changed was set, and there may have been some cases where that wasn't true. Now, LAST-MODIFIED will be included based on $entity->created, if $entity->changed isn't set.
-
- 03 Oct, 2013 2 commits
-
-
Robert Rollins authored
Much like in issue [#1935820], Date's bizarre implementation for repeating date values was causing every VEVENT with an RRULE to be duplicated for each repeat. I fixed the Fields plugin the same way that vlad fixed Entity.
-
Robert Rollins authored
According to the spec, EXDATE properties can have multiple values. However, many popular calendar client don't support that, and only accept iCal feeds which use multiple separate EXDATE properties. That is spec-compliant, though, so I refactored Date iCal to do that for EXDATEs and RDATEs.
-
- 26 Sep, 2013 1 commit
-
-
Robert Rollins authored
The previous fix that I applied for issue #2070883 was the complete wrong way to go about fixing that problem, because it introduced a new, much more sinister issue: the UID for an event would change every time the iCal feed got downloaded. According to the spec, the UID is supposed to be persistent, so I re-engineered the algoithm that creates UIDs for the Fields plugin so it will create the same UIDs as the Entity plugin does.
-
- 20 Sep, 2013 1 commit
-
-
Robert Rollins authored
-
- 17 Sep, 2013 2 commits
-
-
Robert Rollins authored
iCalcreator requires that you *not* call createTimezone($vcal, 'UTC'), because the spec says to use zulu time rather than a UTC VTIMEZONE object. Also fixed a copy-pasta bug that probably never manifested, since it would have only had an effect on events that have an end date that's in a different timezone from the start date.
-
Robert Rollins authored
-
- 11 Sep, 2013 5 commits
-
-
Robert Rollins authored
-
Robert Rollins authored
-
Robert Rollins authored
-
Robert Rollins authored
-
Robert Rollins authored
Also updated the README to reference the iCalcreator GitHub.
-
- 05 Sep, 2013 1 commit
-
-
Robert Rollins authored
-
- 03 Sep, 2013 2 commits
-
-
Robert Rollins authored
-
Robert Rollins authored
-
- 28 Aug, 2013 1 commit
-
-
Robert Rollins authored
-
- 21 Aug, 2013 1 commit
-
-
Robert Rollins authored
-
- 16 Aug, 2013 1 commit
-
-
Robert Rollins authored
-
- 07 Aug, 2013 1 commit
-
-
Robert Rollins authored
-
- 02 Aug, 2013 1 commit
-
-
Robert Rollins authored
-