Wrong use of node_save()

See this:
http://lists.drupal.org/pipermail/development/2008-March/029152.html
If you're ready to step up with a fast and sane way to create nodes (with a patch), i'd be the happiest to trash out the old code.

Noticed this problem when my feedapi-created forum topics didn't show up in forum listings.

Tried adding a call to node_invoke_nodeapi($node, 'load') before the node_object_prepare() call.

No joy.

Tried adding a node_submit() call.

No joy.

lotsa-lotsa-lotsa debugging output -- gonna try creating a new content type and re-creating forums via views.

Wish me luck...

The uid in the {node_revisions} table is not getting set correctly for feedapi-created nodes.

It is always getting set to uid=0, even though the uid is set properly in the {node} table.

Could this be what is causing problems for other modules like pathauto?

http://drupal.org/node/201110#comment-1488576
http://drupal.org/node/432454#comment-1471514

A use case where basically they wanted to keep their feeds up to date but add extra information like taxonomy and cck.
However since feedapi was not calling node_load that data was being lost (calling node_invoke_nodeapi load for new nodes).
Here is part of the diff; we haven't had the time to update to newest feedapi so haven't had the time to make a real patch ATM.

> if (!$feed_item->nid) {
> $node = new stdClass();
> node_invoke_nodeapi($node, 'load');
> // Determines the node type.
> if (empty($settings['content_type'])) {
> $ct_types = node_get_types();
> $ct_options = array();
> if (is_array($ct_types)) {
> foreach ($ct_types as $key => $data) {
> if (!feedapi_enabled_type($key)) {
> $ct_options[$key] = $data->name;
> }
> }
> }
> if (array_key_exists('story', $ct_options)) {
> $node->type = 'story';
> }
> else {
> $node->type = current(array_keys($ct_options));
> }
> }
> else {
> $node->type = $settings['content_type'];
> }
>
> if (feedapi_enabled_type($node->type)) {
> if ($error_msg !== TRUE) {
> drupal_set_message(t('Please disable FeedAPI for !item content-type.', array('!item' => $node->type)), 'error');
> $error_msg = TRUE;
> }
> return FALSE;
> }
>
> // Get the default options from the cont
> $options = variable_get('node_options_'. $node->type, FALSE);
> if (is_array($options)) {
> $node->status = in_array('status', $options) ? 1 : 0;
> $node->promote = in_array('promote', $options) ? 1 : 0;
> $node->sticky = in_array('sticky', $options) ? 1 : 0;
> }
> else {
> $node->status = 1;
> }
> } else {
> $node = node_load($feed_item->nid);
> }

This does not address the issue picking up data /changes to the form during hook_form_alter. Drupal execute would do that, but that'd defiantly be a lot slower. (I've used it a few times to create /update nodes). Could patch it for drupal execute and batchapi also for when running manual refresh (personally I've only used modules patched for batch api so not to knowledgeable about it).

My suggestion is for those with that problem figure out what changes the modules in conflict are doing and mock it in presave or such :/.

where does this snippet go? I'd be willing to test if I knew which file and approx line number and approx what it will replace.

Ooops, sorry for not putting it.

At home and my set up is lacking and don't have the altered file in front of me, so I'm based off the above, memory, and looking at a fresh copy of feedapi.

It's in feedapi_node => feedapi_node.module
The function is function _feedapi_node_save
Around the area where it says "Constructs the node object."

(That function is both update and save; is called by _feedapi_node_update with nid in the $feed_item of the old node).

I haven't looked to see if they've changed anything specifically here (since I was using an old version), so I suggest just redoing what I did instead of that snippit;
in an if not nid, move everything related to creating a new node together including a new call near the top to node_invoke_nodeapi($node, 'load') if nid isn't supplied
else node_load($feed_item->nid)

Let's give drupal_execute a try. I know that it's slow but if people have so many headaches with the current situation, maybe it's worth to try.
Here is a patch. The patch: does not support cross-feed deduping and feedapi_inherit.
Please try it out and tell if your node-related problems have gone or not.
If you can confirm that this approach is seamless (but slow), we can consider to make this as the default way to create nodes.

The patch is okay at the moment, but likely won't apply soon (because of planned commits)
Here is a ready-to-use package, which includes the patch of #13 : http://aron.novaak.net/files/feedapi.zip
The tests and the feedbacks are really welcomed!

#15: as i know, for example CCK field default values are not propagated by only this line

#17 - Kiam, it seems that you're right. i will double check if it works correctly. In fact drupal_execute is somewhat hackish, so i'd be really happy to use only one line to solve many problems :)

drupal_execute() is going to be too slow.

The core issue is that if feedapi does an update, there is no node_load() before it does a node_save(). drupal_execute() would slow down insert and update.

Why don't we add a node_load() when in updateing a node and make it optional with a hidden but documented drupal variable?

"The core issue is that if feedapi does an update, there is no node_load() before it does a node_save()." - just a note: this is not only about the updates. This is a problem at the node create process as well, for example CCK fields are not populated with the default values.
See this: http://drupal.org/node/489046

I haven't used feedapi in a long time. Is this still an issue, or should it be closed?