Feed URL is discarded, feed items not saved (v5.x-1.5)

confirming 5.1.2 isn't working/updating. Some feeds are but some aren't...

Ok, i can only say what i posted at http://drupal.org/node/260670#comment-969353
Please provide more detailed information.

was on my end. the feed was another drupal site which had to have it's node access rebuilt after upgrading to 5.9... i.e. the feed wasn't updating for an anonymous user...

check yer feeds!

heh.

thanks,
kpaul

Have you really entered "feed://" into the URL field? The feed is created fine when I used this url: http://www.campaignforliberty.com/blog/?feed=rss2
"Common Syndication parser doesn't seem to be working at all" - Which version of php do you use? What was the error message?

Same issue here. New install never used any aggs on the site. Uninstalled and reinstalled, went to dev build, no joy.

What I found for mine so far is that some feed urls work, ie my own from my drupal site. In the DB feedapi table I noticed the working url had XML feed for feed type listed. When I replace the feed url from my own site with that of E! Onlines a feed url that works everywhere else save for the feed api common and simplepie aggs, I noticed the feed type goes blank, however the feed url in the db table updates to the new url. If I manually enter XML feed in the feed type column and do a feed agg refresh, feedapi then tells me that there were no new updates even though nothing has been retrieved from the new url.

So from my perspective it looks like feedapi isn't adding the feed type to the feedapi table and bombs. I did get one other message which stated this: Invalid argument supplied for foreach() .... feedapi\feedapi.module on line 1156.

Drupal 5.10
Php 5.2.6
MySQL 5.0.51a
W2k3 Sp2
IIS6

rhylos: It's really annoying to me that I could not reproduce the problem, I used a feed from E! Online. Please contact me via the contact form.
The best would be if you could send the whole test site file structure plus the database dump. In this case I could find out the problem soon.

Solution?
I've encountred exactly the same issue with 5.X, and after some serious debugging I got to the following conclusion. The problem is that _feedapi_build_feed_object is called twice, once from the 'form_alter' (to get the feed title?) and once from the actual update/insert, which means that the second time, the $downloaded_string is already read from cache. But the cached version deosn't have the 'type' so 'parser_common_syndication_feedapi_feed' that is called with 'type' returns nothing, resulting with nothing being saved.

I've changed line 38 in parser_common_syndication.module from
return $downloaded_string->type;
to
return array_shift(parser_common_syndication_feedapi_feed('type'));
and it seems to solve the problem.

Please validate my conclusion.

I just committed what levonai suggested. Others: could you test the fix?

This worked for me. Running the 5.x-1.2 version.

I tried that and no go for me. Form still does not save feed.

I found something that worked for me.

Forget about the "feed" content type that comes from the FeedAPi module.

Create a new content type with all the feed specs you want. Feeds added to that content type were saved.

Having the same problem, I tried #15 and #11 ...

Didn't work for me.
Version: 6.4

ThePrince: Yes, you're right. I fixed a serious issue related to content-type creation. So please delete the built-in content-type, uninstall FeedAPI (make sure you have no feedapi_ variables before installing/enabling the -dev) and install -dev version. It should work.

How can I safely remove feedapi_node content type and recreate one when I already have a lot of feeds in the database? Do I just simply delete it and create a new one with exactly the same name so the existing content still could work with it?

Well, do you experience the problems above?
It's not absolutely neccessary to delete the content-type. You can also go to the content-type edit page and make sure that everything is ok (one parser and one processor are turned ON with fair settings) and save it.

Aron, it worked 2 out 3 times before I upgraded to 5.x-1.5. When I add a new feed (for the feedapi_node content type), the feed URL is not being saved. If I go to edit the node, the feed URL shows blank. I keep posting about the same problem in 2 places - in this thread and over here. Let me know where I should take this.

Ran into same problem with Drupal 5.15 and Feedapi 5.x-15 using Common Syndication. Traced the problem back to lines 404, 487, and 599 within parser_common_syndication.module. Seems that the !empty is not properly reading the parsed XML, even though the XML for the url is there. Simple disabling the if statement seems to be working for me. If you'd rather apply a patch file, here it is.

I'm experiencing the same problem with 5.x-1.5 using the SimplePIE parser (or my slightly tweaked version that adds extra fields). I was able to install two feeds that would actually download records, but any others I try loose the feed URL.

One confusing thing is that I added a simple watchdog() line to the start of each function in feedapi.module to see when the functions were being called, and there were over 700 calls to the feedapi functions. Could one of these calls be canceling out the one that actually counts?

May be related: #372246: FeedAPI looses URL if no parser is enabled

As a newbie, how do I resolve the problem of the feed items not being saved in feed api 5.x.1.x.dev version. I saw Aron's patch that was posted in another comment but the instructions to install patch apply to persons running their own server. Drupal was installed by a web developer for me and I am left with managing it - how do I apply a patch?

I think I identified one scenario where *I* messed up the install, though some error reporting would have helped..
* I had created a new parser module by duplicating one of the existing ones.
* I activated it and configured the feed to use the new parser.
* I decided that in the interests of keeping my directory structure clean that I'd move it from sites/all/modules/feedapi to sites/all/modules.
* It was at this point that the feed stopped working, but I didn't think of it until after scrapping my whole feedapi structure and rewriting it using SimpleFeed.

So.. the moral of the story is:
* Custom parsers must be kept in the feedapi directory,
* Don't move the parsers outside of your feedapi directory after configuring a feed to use it,
* FeedAPI should have checks to ensure that the desired parser is properly available and record a message & fail if not.

Custom parsers can live outside the feedapi directory
Don't move the parsers outside of your feedapi directory after configuring a feed to use it - this is true, but generally: do not change the path of an enabled module. This really make sense, right?
FeedAPI should have checks to ensure that the desired parser is properly available and record a message & fail if not - this changed a lot in the past period. In 6.x-dev, it should tell you nicely if there is a problem with the enabled parser.