Repeat rule no longer being imported.

Hmmm, that's quite odd. It's possible that Feeds' latest dev versions changed the way the $repeat_rule variable gets created. Thanks for finding this, and making the patch. I'll look further into this as soon as I get a chance.

Just wanted to add that I too was having issues with repeat rules not importing - but the patch in #1 fixed it!

Yikes... upon further investigation, it looks like Feeds recently committed a major re-write to their entire codebase in the latest dev releases. That's probably why this problem with repeat rules cropped up. Unfortunately, they never published a stable release before making all those changes, so users of Date iCal are kindof screwed, since it may no longer be safe to use the Feeds dev releases.

If this becomes a significant problem, I'll probably need to start telling users to install the latest recommended release of Feeds, and then apply the patch that fixes the huge bug in 7.x-2.0-alpha8 which breaks all Date field imports.

Also looking for a recommended solution for this. I'd rather not go back to the alpha8 version of Feeds. I realize the -dev version has made a lot of changed, but their support for entities is a positive step forward.

After applying the patch in #1, I still get these errors:

Warning: array_combine(): Both parameters should have an equal number of elements in date_ical_feeds_set_rrule() (line 275 of /opt/development/mpotter/drupal/profiles/openatrium/modules/contrib/date_ical/date_ical.module).
Warning: Invalid argument supplied for foreach() in date_ical_feeds_set_rrule() (line 287 of /opt/development/mpotter/drupal/profiles/openatrium/modules/contrib/date_ical/date_ical.module)

This is when trying to import the Google holiday event feed: http://www.google.com/calendar/ical/en.usa%23holiday%40group.v.calendar....

Will dig into the code a bit to see if I can help.

So, the problem was in this patch. Honestly, the code in the patch really isn't a good way to handle this case. Here is a much simpler patch that also avoids the issue in #5 caused by empty repeat rules.

Now, my events are still not actually being imported. Event nodes are not created. But at least the errors in the change to the callbacks for hook_feeds_processor_targets_alter() are fixed by this patch.

coredumperror: Wow, the more I look into this the worse it gets. I actually am using several modules that do various feed imports, and looks like they have *all* broken with the -dev version of Feeds. So I am looking at going back to the alpha8 as you suggested in #4. Do you have a link to the patch that fixes data_ical for the alpha8 version of Feeds?

So far I can report that it seems to be a problem with the case-sensitivity of the mappings. The fields in the iCal import file are uppercase. The $source mappings have uppercase keys. But somehow when Feeds performs the mappings, it is using lower-case names for the source fields. So it tries to set the Title of the node to $source['summary'] instead of $source['SUMMARY'].

Note sure if this is left-over configuration stored in my database from previous versions or if something else has changed, but continuing to investigate.

Looks like the case-sensitivity problem was my own. When I recreated my Feed Importer feature, it properly exports the source keys as uppercase. After fixing this the patch in #6 is working well for me now.

So no need to revert to alpha8 feeds I don't think.

So if I'm reading this right, by applying patch #6, you can successfully import events using Date iCal and the latest -dev version of Feeds?

The patch in #6 does resolve the issue with importing repeating dates, at least with Google Calendar. However, it was never committed to the module.

Hmm, interesting. I'm not sure why I would have closed this issue without applying the patch, if it was needed, so something else may be causing your problem.

Do you have Feeds 7.x-2.0-alpha8, with the patch from here installed? Or are you using a newer dev build of Feeds? Newer dev builds don't work right with Date iCal.

Ah, that could be it. I'm using a dev version. I'll see if I can test the alpha 8 version with the patch.

Patch still applies!

This issue is caused by an API change in the dev version of Feeds, see the change record: https://www.drupal.org/node/2301995

#2291345: Mapping to date repeat rule not working deals with the exact same issue, so I closed that one as a duplicate. Attached the patch from there as that one also updates the function documentation according to the change record. The patch should be backwards compatible with Feeds 7.x-2.0-alpha8.

I also closed #2479655: Date repeat rules not getting imported as a duplicate.

Is that patch sufficient to make Date iCal compatible with the newest dev builds of Feeds? I'd love for Date iCal users to be able to use Feeds dev, rather than having to fall back to alpha8 with the patch I backported.

Sorry for the late reply. The patch in #18 only fixes importing the repeat rule. I haven't investigated if there are other incompatibilities between Feeds and Date iCal, but I know there are more date related issues in the Feeds issue queue like #2363923: Date Field Problem with mapping and #1058424: Port date mapper patch to d7 version to support dates before 13 Dec 1901 (which was recently fixed).

With Feeds having finally released a new official version, I tested your date_ical patch against it, and it definitely fixes the RRULE import functionality! I'll be pushing up a patch to date_ical that incorporates your work momentarily.

I think this issue is still hanging around. I am getting:

Warning: array_combine() [function.array-combine]: Both parameters should have an equal number of elements in date_ical_feeds_set_rrule() (line 280 of .../sites/all/modules/date_ical/date_ical.module).
Notice: Undefined offset: 1 in _date_ical_parse_repeat_rule() (line 138 of .../sites/all/modules/date_ical/date_ical.utils.inc).

Importing items from a Google calendar. The warnings popped up on cloning an event that had no recurring option.

This is probably a separate, if related issue. Could you open a new ticket for this, please? When you do, please explain what you mean by "cloning".