GitLab

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.

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.

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.

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.

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.

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.

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.

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.