There is a similar thread here but for the drupal 6 version of node_export. This is also happening in drupal 7.

When exporting nodes that are linked via translation, they share a tnid value. That tnid value is equal to the nid value of one of those nodes. However, on import the node_export module nulls out the nid (b/c it is creating new nodes, and doesnt want to overwrite existing nodes). This change in nid breaks the link between the nid and tnid, causing the tnid to reference a non-existent node, or a different node all together.

I have written a patch for this. I'm not sure if it covers all scenarios, since I am not intimately familiar with the module. However, for the small imports I am doing it seems to be working great.

The patch only overwrites the tnid value when it detects that it matches the nid of a node being imported. Otherwise the tnid is left alone, so as to preserve existing functionality of importing the tnid as specified. This is a valid use case, where an existing node is having a new translation imported.


Status:Active» Needs review
new2.54 KB

new2.76 KB

Made a slight tweak to the patch, to prevent the tnid from being updated for node imports that are simply revision updates on existing nodes. Technically, the tnid won't be updated in these scenarios with the patch in #1, but it will cause an extra, unnecessary node save.

@HitmanInWis, thanks for the patch. You wrote:

As such, when importing a set of nodes that are all linked via tnid, it is necessary that the first node where nid = tnid is imported prior to any of the other nodes that share that tnid.

This order is not guaranteed when exporting so to be sure everything works we have to make node_export export the original (tnid==nid) nodes first. Will try to submit a patch soon.

Issue summary:View changes
new3.78 KB

The patch that ensures proper ordering of translated nodes.