dougm discovered this issue, and my initial testing seems to indicate that his errors are comoing from Date iCal not properly importing VEVENTs which have both RRULE and DTEND elements. Maybe. I'm still looking into it.

The attached zip includes the iCal feed that causes the errors, and the the .pdf file that shows the error messages.

CommentFileSizeAuthor
error feed and messages.zip239.6 KBcoredumperror

Comments

coredumperror’s picture

coredumperror commented
Title: Importing VEVENTs with both RRULE and DTEND elements is broken » Importing VEVENTs with RRULEs breaks sometimes
Priority: Major » Normal
Status: Active » Postponed (maintainer needs more info)

I can't reproduce the error messages that you get, dougm. Could you please try again using the code in the 7.x-2.x-dev release linked on the project page?

Also, could you include screenshots of your Feeds parser settings pages? It's possible that you've got something configured wrong, which is why I can't reproduce this.

dougm’s picture

dougm commented

I haven't forogotten about this. I should have time after this weekend. We decided to go live without the calendar and add that once the problems are resolved.

beeradb’s picture

beeradb commented
Status: Postponed (maintainer needs more info) » Active

It looks like this is still happening. Unfortunately, I can't provide a .ics file at this time because the one it's failing on for me contains sensitive info.

The issue looks to be that formatDateTime within the DateIcalCreatorParser class is returning FeedsDateTime object. If you look at the feeds mapping code, (feeds/mappers/date.inc) it does a check on the date using date_create. When you pass date_create an object the warning is thrown. Changing the relavent feeds code to !date_create($f->date) makes the date parse correct.

I don't know feeds well enough to know if this is an issue in how things are being processed in date_ical, or a bug within the feeds date mapper, but I'll keep digging.

coredumperror’s picture

coredumperror commented

That does give me enough info to at least make a hack that should work, so I'll see what I can do.

beeradb’s picture

beeradb commented

@coredumperror: After looking into it more I now believe this is an issue with feeds. The date.inc mapper documentation states that it is flexible about input between a string and a FeedsDateTime object. However, it indiscriminately passes $f into date_create, which I believe is incorrect. Since a FeedsDateTime object is incorrect input into date_create, it should do a check first.

I don't know enough about feeds internals to know every use case, but I believe the line should be:

if (empty($f) || !is_numeric($f) && !$f instanceof FeedsDateTime && !date_create($f)) {

instead of:

if (empty($f) || !is_numeric($f) && !date_create($f)) {

I'll be submitting a patch to the feeds module for this and get feedback from maintainers there. I'll cross-reference that issue here once it's created.

beeradb’s picture

beeradb commented

The feeds issue is over at http://drupal.org/node/1989196

coredumperror’s picture

coredumperror commented

OK, cool. Thanks for your help!

coredumperror’s picture

coredumperror commented
Status: Active » Closed (duplicate)

This has been fixed in the latest dev version of Feeds, as mentioned in #1989196: Never Pass FeedsDateTime objects into date_create.