Node Creation

Keep in mind that changes to the content type are not propagated to existing feed nodes. Only newly created feed nodes are effected.

#2: thanks for clarification, this sounds like a critical bug to me. I'll bump this issue to critical to make sure we address this for the 1.7 release. Can't take a look at it right now though. Any further insights/fixes are very welcome. I suppose something is wrong when feedapi_node retrieves the node type from $settings when creating feed items from feeds. Do you happen to have 'refresh on creation' on?

I was experiencing the same problem when I recently set the option to 'refresh feeds on creation'. The first feed items would choose a different node type to that specified in the feed.

I also found these old threads with the same problem, although they were solved previously:
http://drupal.org/node/236863
http://drupal.org/node/207773
http://drupal.org/node/231472

Unfortunately I didn't get as much time to look at the problem as I would've liked, but maybe what I've found can help others.

Around line 805 in feedapi/feedapi.module, the settings are being passed to the refresh function as follows:

        $node->feed->settings = $settings;
        feedapi_invoke('refresh', $node->feed);

These settings are populated correctly. However in the _feedapi_invoke_refresh function, the settings are retrieved again from the database.

This is returning empty settings for the newly created feed. I didn't have a chance to investigate why this is but I would guess it has something to do with the feed being newly created.

What I did to solve this problem was to tell it instead to use the settings that have been stored in the node previously. So I changed the line (around line 1108)

from:
     $settings = feedapi_get_settings(NULL, $feed->vid);
to:
     $settings = $feed->settings;

This caused the items to use the right settings and create the feed items as the correctly specified content type. I'll have to do more testing to see if there are any negative effects from this (with the above code, I'm assuming that the $node object will always already have the settings assigned which very well may not be the case).

I could reproduce the problem.
Here are two patches to fix the issue. (the style is different, only ONE patch should be applied finally)

I'll test both patches (separately) in the next few days and report my findings. Thanks again.

#7: Could you explain what's the difference between the approaches, and what are the pro and cons for each?

Of course. In the longer version, the invoke_refresh... does not try to fetch the settings if it's already in the $feed object. But who cares? get_settings() serves it from a static variable.
I vote for the short version.

Short version it is, then.

#8, Gomez_in_the_South : could you test the patches already? If not: focus on the short patch. I'd like to see whether this is addressing the issues you've reported.

Thank you.

I reverted to the previous version that was causing the problem I described in #6. However creating new feeds worked as it should. i.e I was unable to re-create the problem. I double checked the code as well as cleared the cache so I'm not sure why it is now working. I'm not aware of any other settings that I've changed since, but the site is under active development so it is a possibility.

Anyway, I applied the shorter patch and tested both the creation of new feeds and refreshing of existing feeds and they work as they should. I'm not sure of the reasons for the inconsistency, but I'm pretty confident that the patch is necessary.

Let me know if I can help further.

#13: Thanks for checking so quickly, this really helps.

Yes, the patch is absolutely necessary (pretty obvious bug). I wanted to make sure that it addresses the issue you've reported. I think this is RTBC now (short version).

The short version is in.