I looked but didn't see this issue in the queue. It seems to me that when I have a new feed setup to associate the nodes with the group(s) of the parent feed, and also have the feed setup to pull down the data at creation time, that the group associations aren't there. However, an update of the feed creates those associations. So it sounds like the processors may be firing before the initial grab, or not at all.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | feedapi content type settings.png | 67.34 KB | rconstantine |
| #2 | feedapi feed node not working.png | 37.29 KB | rconstantine |
| #2 | feedapi feed node working.png | 37.94 KB | rconstantine |
Comments
Comment #1
rconstantine commentedI'm not sure whether this is a symptom of the same issue, or a different issue altogether, but I noticed that in the feed_api_node_item table, that some items do not have GUID entries. What are GUIDs, and when are they set?
Anyway, something else I noticed was that the hook_nodeapi implementation for the inherit module only implements the 'prepare' case. Is this doing the job properly?
Also, the weight of having the node module fire before inheritance and visa versa doesn't seem to matter. A manual refresh still seems to be required either way in order to make the proper group associations, though sometimes I get an error telling me the feed wasn't updated, in which case, the OG stuff IS NOT associated with the item nodes. Bummer.
Changing whether a 'refresh' runs at feed creation time or not doesn't seem to matter.
My biggest concern is whether new feed item nodes related to an existing feed will automatically contain the group associations, or if I will have to constantly (daily) run manual refreshes.
Comment #2
rconstantine commentedAlong the GUID lines: those without GUIDs give me the "Could not refresh feed." error and these are the ones that when refreshed, naturally never get the OG stuff associated with them.
Incidentally, I also just noticed that the two feeds giving me issues are ones supplied by the sites containing the articles. The ones that work are those from an RSS creation service. So I would imagine that this really has something to do with not getting the 304 (is that the right number?) status message, right?
So I'm leaning to the idea that the inherit module isn't firing at the right time during node creation and isn't being called at all when the 'refresh' is called but the RSS feed document hasn't changed, which means the 304 condition is met.
This is related: http://drupal.org/node/202351, but note that my complaint is that og associations are NEVER set, even from the beginning.
I know I'm rambling, but I didn't get much sleep last night. Let me provide details of my setup and two feed URLs - one that is fine, and another that isn't.
See the attached screen shots.
Notice that the settings for the feed that is working are the same as those that aren't. Also notice the two URLs. With those from PonyFish, I have no problems (once I do a manual refresh), though I'll have to check if the new items found via cron are properly associated with og or not.
Comment #3
rconstantine commentedPossibly related:
http://drupal.org/node/195816
Comment #4
aron novakCan you try out the following? :
Grab the Revision 1.1.2.10 - Tue Oct 30 22:11:22 2007 UTC (2 months, 1 week ago) by aronnovak version files of feedapi_inherit from the CVS and replace feedapi_inherit files with the newly downloaded files (the easiest way to use webcvs for this)
Try out what happens
Thanks in advance!
Comment #5
aron novakComment #6
rconstantine commentedI'll do that.
Comment #7
rconstantine commentedThere seems to be no difference. What I did was this:
1) Delete an existing feed node
2) Delete the 5 item nodes
3) Recreate the feed node using the same settings as before (including refresh at creation) which had FeedAPI Node above the Inherit processor in the list.
4) Check the message displayed: 5 nodes created, none updated, feed created. Looks good.
5) Clicked "Feed Items" link (provided by Node Views); yes all five nodes were created.
6) Go to group home page which the feed node was assigned to; item nodes not there.
7) Refresh feed - strange: now I get a message that 5 new nodes were created, 0 updated.
8) I reloaded the group home page; now the item nodes are there.
9) I checked the "Feed Items" link again and there are only five nodes, not 10 as the above messages would seem to indicate.
Anything else you would like me to try? I'm going to switch back to the new code unless you think I should do otherwise.
Comment #8
aron novakWell, i think it's the same like: http://drupal.org/node/206840 . Can you ensure me? If yes, i mark this one as a duplicate. I think the root of the problem is the same in these two tickets. The inheriting logic is not called in every case when necessary.
Comment #9
rconstantine commentedSorry, but I don't think they are related like I thought. Now that I moved the module to a Linux box as I mentioned in the other issue, I can report that I still have to refresh the feed once it is created and that certain feeds (those not created via an online feed generator - i.e. screen scraper) can't refresh until there is new content.
For example, I have a feed from a newspaper that they provide. I create a feed content type using that feed address. It creates correctly and creates all child nodes correctly except that the group is not inherited. So if I go to the group, I see the post for the feed itself, but not any of the nodes. If I click on the link from the feed to show the articles, I see the list and can navigate to any of the new nodes. If I try to refresh the feed, I get an error telling me the feed can't be refreshed. Once there is a new item in the RSS feed, the older items are updated and added to the group, but the new item is not. In my case, cron runs every hour, but this feed didn't have something new for about a day. BTW, this happens with any feed which comes direct from a site and not generated via a third party.
However, using a feed from 'PonyFish', I setup the feed node in the same way and have the same problem with the articles not being associated with the groups. Refreshing the feed in this case works, though, and the nodes are then associated with the group and browsing to the group shows as much.
The only difference between now and post #7 is that the message in list item 7 now shows no new nodes, and however many nodes originally created as updated. So it looks right, except that the association with the groups should happen right away.
I wish I could be more help right now. Usually, I help come up with patches, but I'm swamped with work and falling behind on my own module maintenance. I hope you can figure this out. Thanks for your work.
Comment #10
aron novakFinally i could reproduce the bug. I'm still trying to fix the bug.
http://www.ponyfish.com/feeds/26547tyZwdzJU - this one is perfect
but the other mentioned feed really does not work, despite the fact that the feed is valid.
Comment #11
aron novakFinally i caught the bug. FeedAPI 's weight was 0, so it was indeterministic that feedapi or og hooks are called first. When feedapi_inherit tried to update og info, the og info for main feed was even not saved. That was the problem. I committed the fix. You have to run the update scripts to get the things properly work!
Comment #12
rconstantine commentedGreat news!
Comment #13
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.