I recently updated my site to the latest dev versions of Date iCal, Feeds, and Date to confirm a different issue I was having. When I did so, my repeat rules started failing to import. I was getting errors on line 273 of date_ical.module regarding an invalid second parameter for explode being an array when it should have been a string and then the following error as well.
Warning: explode() expects parameter 2 to be string, array given in date_ical_feeds_set_rrule() (line 273...
A quick call to dpm revealed that $repeat_rule
is array(0=>string) rather than string.
I modified the line to use $repeat_rule[0]
instead and that fixed the problem and the rrule was imported correctly again. I'm including a quick patch that checks if the passed value is an array that matched what I saw and then adjust accordingly, otherwise it falls back to the old code. I'm not sure if this is correct or kosher.
Comment | File | Size | Author |
---|---|---|---|
#18 | date_ical-feeds-repeat-rule-2291345-26.patch | 845 bytes | MegaChriz |
#6 | date_ical-irule-array-2206109-6.patch | 530 bytes | mpotter |
#1 | repeat_rule_as_array-2206109-0.patch | 1.01 KB | RedEight |
Comments
Comment #1
RedEight CreditAttribution: RedEight commentedComment #2
coredumperror CreditAttribution: coredumperror commentedHmmm, 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.Comment #3
chippper CreditAttribution: chippper commentedJust wanted to add that I too was having issues with repeat rules not importing - but the patch in #1 fixed it!
Comment #4
coredumperror CreditAttribution: coredumperror commentedYikes... 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.
Comment #5
mpotter CreditAttribution: mpotter commentedAlso 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:
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.
Comment #6
mpotter CreditAttribution: mpotter commentedSo, 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.
Comment #7
mpotter CreditAttribution: mpotter commentedComment #8
mpotter CreditAttribution: mpotter commentedcoredumperror: 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?
Comment #9
mpotter CreditAttribution: mpotter commentedSo 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.
Comment #10
mpotter CreditAttribution: mpotter commentedLooks 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.
Comment #11
coredumperror CreditAttribution: coredumperror commentedSo 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?
Comment #12
coredumperror CreditAttribution: coredumperror commentedComment #14
Poieo CreditAttribution: Poieo commentedThe patch in #6 does resolve the issue with importing repeating dates, at least with Google Calendar. However, it was never committed to the module.
Comment #15
coredumperror CreditAttribution: coredumperror commentedHmm, 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.
Comment #16
Poieo CreditAttribution: Poieo commentedAh, that could be it. I'm using a dev version. I'll see if I can test the alpha 8 version with the patch.
Comment #17
hefox CreditAttribution: hefox commentedPatch still applies!
Comment #18
MegaChriz CreditAttribution: MegaChriz commentedThis 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.
Comment #19
MegaChriz CreditAttribution: MegaChriz commentedI also closed #2479655: Date repeat rules not getting imported as a duplicate.
Comment #20
coredumperror CreditAttribution: coredumperror commentedIs 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.
Comment #21
MegaChriz CreditAttribution: MegaChriz commentedSorry 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).
Comment #22
coredumperror CreditAttribution: coredumperror commentedWith 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.
Comment #24
coredumperror CreditAttribution: coredumperror commentedComment #26
mjkovacevich CreditAttribution: mjkovacevich as a volunteer commentedI think this issue is still hanging around. I am getting:
Importing items from a Google calendar. The warnings popped up on cloning an event that had no recurring option.
Comment #27
mjkovacevich CreditAttribution: mjkovacevich as a volunteer commentedComment #28
coredumperror CreditAttribution: coredumperror commentedThis 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".