GitLab

When I wrote up a fix for one of the changes made in the newest version of Feeds,
I put the fix a few lines after it should have gone. This resulted in blank
RRULEs going undetected when those versions of Feeds are installed, making the
parsing code attempt to parse a blank string, which threw warnings and notices.

I'm a complete idiot, and totally failed to test the iCal import functionality
with iCalcreator v2.22. Turns out, the author made much more significant changes
to the library than I'd thought, and those changes completely broke the import
process. With several hours of work, I could probably re-write Date iCal to
support these changes, but those re-writes would necessarily make Date iCal
incompatible with v2.20.2 of the library, which would break every existing Date
iCal install the next time they update, unless they also update iCalcreator.

Thus, due to my lack of available time, and the update incompatibility problem,
I'm just declaring that Date iCal 7.x will not support iCalcreator v2.22, ever.
If someone comes along to make a Drupal 8 version, they could choose to put in
the time to re-write the guts of the import code to make it v2.22-compatible.

I'm not sure what changed to make the old code stop working (updates to the
Date module, perhaps?), but it was definitely not rendering RDATE and EXDATE
properties correctly. Sadly, RDATEs are still broken in all Apple-based calendar
apps, but that's their fault.

I used to like keeping whitespace on blank lines that lined up with the
indentiation level of the code. I don't like doing that any more, so out it goes.

I was very sleepy when I applied this patch, and didn't think through what it
was doing. The user who submitted it was actually just using Address Field wrong.

Thanks go to user pc-wurm for discovering this bug. Being in the United States,
I hadn't noticed that "US" was actually the country code, rather than the
country name, which is what Date iCal should have been rendering into the
LOCATION field.

Thanks go to d.o user MegaChriz for this fix!

Issue #2482643: Updated README and drush makefile to account for iCalcreator non-backwards compatibility.

iCalcreator v2.22 is not backwards compatible with v2.20.0 and earlier, meaning
it doesn't work with Date iCal.

Many thanks go to d.o user bjlewis2 for pointing that out.

Previously, the time value was pulled from the Date field, rather than the
RDATE field. Now it'll pull from the RDATE field if it has a time, and fall
back on the Date field if RDATE doesn't.

Because the iCal spec states that VFREEBUSY components can't have the
SUMMARY property, Date iCal will now fall back to the COMMENT property
for the node title. Unfortuantely, this is the best we can do, becaise
iCalcreator completely leaves out the SUMMARY property on VFREEBUSY
componeents, so there's no way to recover it.

Thanks go to user mgalman for the patch!

iCalcreator knows that certain iCal properties (e.g. ATTENDEE) can have
multiple entries in a single VEVENT. So when you access ATTENDEE for the
first time, it gives you the first entry. Accessing it a second time gives
back the second entry, or at least it tries to. If there is no second
entry, iCalcreator returns False.

Since Date iCal does not yet support multi-entry properties, I had to work
around this functionality to ensure that hooks which add custom mappings
don't run afoul of this process.

This patch is courtesy of Drupal user cdmo.

Thank you t0xicCode for this patch!

User RedEight pointed out that I messed up the parse regex for UNTIL values
when I made the recent change regarding DATE-type UNTILs. That's fixed, now.

In addition, I tweaked the iCalcreator version detection regex to be a bit
more forgiving of any possible changes the author makes in his version
definition code.