This was spanwed from a date_ical issue over at http://drupal.org/node/1886580.

It turns out date_ical returns FeedsDateTime objects to be mapped. Under certain situations the feeds mapper will pass this object into date_create, which takes a string as input. This causes lots of warnings to be printed.

There may be other issues at play, but just adding a check within the mapper to ensure a FeedsDateTime object isn't being passed into date_create fixes the issue for me.

CommentFileSizeAuthor
#11 feeds-fix_datetime_conversion-1989196-11.patch1.46 KBcoredumperror
#1 1989196-feedsdatetime-check.patch548 bytesbeeradb
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

beeradb’s picture

beeradb CreditAttribution: beeradb commented
Status: Active » Needs review
FileSize
1989196-feedsdatetime-check.patch548 bytes
Matthew Davidson’s picture

Matthew Davidson CreditAttribution: Matthew Davidson commented
Status: Needs review » Reviewed & tested by the community

Works for me and at least one other person.

aDarkling’s picture

aDarkling CreditAttribution: aDarkling commented

+1
Works for me as well.

Feeds wasn't able to import or map dates from a CiviCrm ical event feed (version 4.2.2). This fixed that.

The code change appears solid and contained.

twistor’s picture

twistor CreditAttribution: twistor commented
Status: Reviewed & tested by the community » Fixed

I think I've fixed this. I just went ahead and made the check for a string, since that's what date_create() expects.
Also fixed multivalue handling while I was in there.

http://drupalcode.org/project/feeds.git/commit/7e6679d

beeradb’s picture

beeradb CreditAttribution: beeradb commented

Good improvement. I realized after I had posted the patch that it shouldn't be as specific as checking for the feedsdatetime object, but just never had a chance to circle back and post the update. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

cdmo’s picture

cdmo CreditAttribution: cdmo commented

I realize this patch is for 7.x-2.x-dev, but I applied the patch in #4 to 7.x-2.0-alpha8 and it worked for me. Thanks!

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan commented

Marked #1988562: Begin and end date not beeing parsed (iCal from google calendar) and #1669964: Multiple Values and Empty Values in Date Fields as duplicates of this issue.

coredumperror’s picture

coredumperror CreditAttribution: coredumperror commented
Status: Closed (fixed) » Active

Please forgive me if I'm just reading this wrong, but the updated function confuses me:

function date_feeds_set_target($source, $entity, $target, $feed_element) {
  list($field_name, $sub_field) = explode(':', $target, 2);

  if (!is_array($feed_element)) {
    $feed_element = array($feed_element);
  }

  $delta = 0;
  foreach ($feed_element as $f) {

    if (!($feed_element instanceof FeedsDateTimeElement)) {

      if (empty($f) || !is_numeric($f) && is_string($f) && !date_create($f)) {
        $f = new FeedsDateTimeElement(NULL, NULL);
      }
      elseif ($sub_field == 'end') {
        $f = new FeedsDateTimeElement(NULL, $f);
      }
      else {
        $f = new FeedsDateTimeElement($f, NULL);
      }
    }

    $f->buildDateField($entity, $field_name, $delta);
    $delta++;
  }
}

Right near the top, it checks if $feed_element is an array, and makes it an array if it's not. And with the new change, it later checks if $feed_element is a FeedsDateTimeElement, which it can never be because of the above array code.

Shouldn't that second if be checking $f instead of $feed_element?
if (!($f instanceof FeedsDateTimeElement)) {

dgeo’s picture

dgeo CreditAttribution: dgeo commented
Issue summary: View changes

Same here: not sure about how to understand this piece of code, but testing in the enumeration loop an impossible property of a parent element seems - at least - a bit strange…
I've tried here with the change proposed in #9, it works too…

coredumperror’s picture

coredumperror CreditAttribution: coredumperror commented
FileSize
feeds-fix_datetime_conversion-1989196-11.patch1.46 KB

Here's the patch I've been using to fix this issue. It's essentially the same as the commit linked in #4, but with the $feed_element -> $f fix applied.

coredumperror’s picture

coredumperror CreditAttribution: coredumperror commented
Version: 7.x-2.x-dev » 7.x-2.0-alpha8

Oops. The patch in #11 is for alpha8, not the current dev.

twistor’s picture

twistor CreditAttribution: twistor commented
Issue tags: +Close on release

Just a note, the bug reported in #9, and patched in #11 was fixed a while ago, but this issue is left open until we get a new release since the patch is for alpha-8.

dgeo’s picture

dgeo CreditAttribution: dgeo as a volunteer commented
Status: Active » Fixed

now beta4, I close this according to #13

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.