I tried to update to the latest version and the import of nodes isn't working anymore. I searched a bit and it seems that the problem is coming from the json modification introduced in this commit (Works well when I remove that modification) :
http://drupalcode.org/project/node_export.git/commitdiff/ec5ea03

CommentFileSizeAuthor
#11 1624514-11-not-working.patch472 byteslinclark
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

milesw’s picture

Same here. Nodes are reported as being created, but they aren't actually being saved. I can confirm that things work after reverting to the commit referenced by the OP.

danielb’s picture

What exactly do you mean "import of nodes isn't working anymore", and can you tell me about what settings and format of export you're doing?

danielb’s picture

Is it consistent with milesw's report that nodes are reported as created but are not?

Are you sure the node doesn't already exist on the site, because node export deals with that case differently now too.

danielb’s picture

That change you guys are refering to is rather innocuous, and simply serves to prevent the json format from claiming ownership of imports that it shouldn't. I can't see how that would make such a difference, especially if you're not using json. If you are using json, then if the new if statement doesn't evaluate it should report 'invalid format'.

jsacksick’s picture

Yes I'm sure, the node isn't created, you get the message that says Imported node !nid etc... but at the end none of the nodes are created. I suspect the json modification.

danielb’s picture

I'm struggling to understand why this would have such an effect.

If the message reports it was imported, something went through. Isn't there a link to the new node in that message? Where does that link take you?

milesw’s picture

@danielb: In my case the nodes definitely don't already exist.

- The features component contains 1 node and shows "Overridden"
- I revert the Node Export component
- I see the following message:

Reverted all node_export_features components for test_content.
Imported node 181897: Add your listing
1 of 1 nodes were imported. Some values may have been reset depending on Node export's configuration.

- Node 181897 is the original NID from the source site. This new site only has 370 nodes.
- The link in that status message, which points to a path alias, produces a 404. It's not the alias exported with the node either, it appears to be generated by pathauto on the new site.

Maybe that gives you some clues. I'll try and dig in further when I get back to working on that end of things.

danielb’s picture

Is this possibly related to

#1611848: Do a better job cleaning nodes when exporting via features. Helps avoid features thinking a node is constantly 'Overridden'.

Try editing 'changed' and 'created' to NULL in the export code ?

danielb’s picture

Status: Active » Postponed (maintainer needs more info)

also
#1630478: Reverting a feature causes nodes to be duplicated

those are drupal 6 issues, but chances are this is a problem with both versions.

Anonymous’s picture

I am working with a completely fresh install.

I was just testing it out to see how the module works so I created 2 nodes, built the feature, drush si-ed, and tried installing it. The status message said both had been created and showed their titles, but there are no nodes in the database.

If I have a chance tomorrow, I'll try to debug more.

Anonymous’s picture

Status: Postponed (maintainer needs more info) » Needs review
FileSize
472 bytes

In node_export_import, if a node has an nid, it will not have the $node->is_new flag set, even if it is new to this site. Changing this if statement fixed the problem for me.

The code in this patch checks whether any existing content was loaded for the nid. If no existing content was loaded, it sets the is_new flag to TRUE.

danielb’s picture

I'd rather not change node_export_save() any further. The code calling node_export_save() should sort the node out. Identifying whether the node exists already should be based on uuid not nid.

danielb’s picture

specifically this code:

<?php

    if (!empty($nids[$node->uuid])) {
      $existing = variable_get('node_export_existing', 'new');
      switch ($existing) {
        case 'new':
          $node->is_new = TRUE;
          unset($node->nid);
          unset($node->uuid);
          break;
        case 'revision':
          $node->nid = $nids[$node->uuid];
          $node->is_new = FALSE;
          $node->revision = 1;
          break;
        case 'skip':
          $save = FALSE;
          break;
      }
    }

?>

should have an 'else' or something to handle a new node situation

danielb’s picture

I'd say when that code was added (recently) the original code that would work for your case was mistakenly removed

danielb’s picture

nope i'm wrong there was nothing there before

danielb’s picture

oh I think I know what happened
in node_export_node_clone() the following line is commented out in the repository:

  $node->nid = NULL;
danielb’s picture

ok i've restored that, the next dev should behave properly

Anonymous’s picture

Thanks, I pulled down the change and it now works for me.

danielb’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.