Error Importing Google Calendar Feed As Node

I'm experiencing a similar error message. I'm on a Windows server and the feed is from Outlook vi Webdav.

This seems to be coming from the external library, ICalcreator. So I have tried a short php script to parse my ICS file directly. It parses fine, the only difference is that I'm loading it as a file not a stream with a URL. How would that make a difference?

Thank you.

The iCalcreator library checks the url given, and returns false if it is not "http". If I comment out lines 803 and 804, and run the feed import. It works!

From iCalcreator.class.php version 2.16.12 lines 800 to 814 --

      case 'URL':
            /* remote file - URL */
        $value     = str_replace( array( 'HTTP://', 'WEBCAL://', 'webcal://' ), 'http://', trim( $value ));
        //if( 'http://' != substr( $value, 0, 7 ))
        //  return FALSE;
        $s1        = $this->url;
        $this->url = $value;
        $s2        = $this->directory;
        $this->directory = null;
        $parts     = pathinfo( $value );
        if( FALSE === $this->setConfig( 'filename',  $parts['basename'] )) {
          $this->url       = $s1;
          $this->directory = $s2;
          return FALSE;
        }

I also tried to debug the issue, and the fix in #3 didn't work for me.

My main lead was that the module seems to download the ical file with curl, then runs iCalcreator on the file locally. However, Drupal uses a stream wrapper for the downloaded file (public:///foo.ics), and iCalcreator seemed to think that this is an URL rather than a file on the disk. Maybe that's OK, considering it's a bit the point of stream wrappers, but the code sometimes has weird assumptions. I tried using drupal_realpath(), but no success.

Also, in my case, the http link of google redirects to https. You can test on the command line with wget/curl to see if it's the case.

Fwiw, I'm not sure if it was just a cache issue (APC), but #3 now works for me.

Hmmm, strange. I've successfully imported nodes from Google Calendar before, so I'm not sure what's changed that broke it for you guys. I'll look into it as soon as I get a chance.

Note: Patch in this comment is abit wrong. Have another one in the next comment though :)

Fix described in the #3 comment fixed the issue for me, but it is not the correct solution as we cannot make patches for the 3rd party library.

I propose to change the way how data is read from feeds import. Instead of using the filename (which contains the "public://" part) the module should send raw data to the "vcalendar" class "parse" function. I am not sure, but this method could be troublesome with larger iCal files.

Patch included.

Any thoughts are welcome :)

Improved patch for comment #10

Upon doing some testing, I haven't been able to reproduce this problem. I can successfully import Google Calendars that I made for testing.

So if I'm going to fix this issue, I need some help from you, DaveMolinero. Could you please tell me the exact URL you're using to pull your Google Calendar? Could you also please attach the actual ICS file? If you don't want to make that information public, you could send it to me directly using the Contact tab on my profile page.

The exact wording of the error message you reported makes me think that it might be because of a TODO element, which Date iCal may not be able to handle. But I've never seen an ICS with with a TODO, and I don't know how to make one.

@kait I applied and tested your patch, and it seems to work fine. But I'm not entirely certain what problem it's supposed to be solving. Could you elaborate, please?

I'm facing the same problem - I created a test calendar in Google, made it public, added a couple of events, and then used the url to try things out: https://www.google.com/calendar/ical/nbp8vgts9slr99ido7gfrk2gq8%40group....

When that simple test failed, I backtracked the work done by @ejwettstein in #3 to understand better.

The issue is: iCalcreator wasn't built with stream wrappers in mind. Therefore, when you store a value that starts with "public://" into $config['url'] and pass it as you're doing in DateIcalIcalcreatorParser::parse(), the underlying library rejects it as an invalid url - and rightly so. 'public://' isn't a legitimate protocol, and the iCalcreator library tosses it out - therefore we end up with an empty vcalendar object, and the call to parse() fails.

So we need to pass it something that iCalcreator will actually work with. Since feeds already has a file for us, we just need the file system path from Drupal, and then we can pass 'directory' and 'filename' config parameters instead of 'url'.

As @kait has suggested, there might be problems slinging large chunks of text around - and we can actually still use the stream wrapper to get at the data we care about. This appears to be one of the rare cases where drupal_realpath() is the right thing to use. (There's an argument in the world of Drupal core about this function and how it shouldn't be used...the case that it can safely be used for is exactly this: passing values to a library that doesn't handle stream wrappers...)

Hope the explanation (and the patch) helps.

@dsayswhat in comment #13 describes very well the problem this module has with iCalcreator library (start reading from the 3rd paragraph). Although I have one gripe with his solution - doesn't it make the iCalcreator read the file even though the $fetcher_result variable already contains the file's content?

Huh, maybe my site's configuration leads to some sort of odd "works even though it shouldn't" situation, but that Google calendar you linked works just fine for me. I can import the "lunch" and "dinner" events, and I get no errors.

I've pushed the patch from #11 up to git, so once a -dev build from today (Feb 27) appears (it'll take many hours, sadly), please download that to see if it fixes this problem.

The patch from the dev version worked for me

I had the problem before trying the dev version. My output was from Yahoo Pipes. I put together a 3-line script where the iCalcreator library grabbed the file directly from Yahoo, no problem whatsoever.

The 'todo' is coded into the module, as though a developer was leaving a note, to finish that error message with something other than 'todo'.

Glad to hear that the patch worked. I also went into the code and removed that "todo". Thanks for pointing that out!

I ended up using the dev patch, though #13 worked also. Thanks everyone.