TNID not being updated on source when sync is enabled (not using "Entity Cache" module)

Please post some step by step instructions on how to reproduct.

> I have not been able to reproduce it on a clean install with just the modules

Ok, then reopen if you can reproduce the error. Otherwise we'll assume it is caused by any of the other modules...

This is linked to the node_load static cache to return outdated data. This issue was already fixed some years ago: https://drupal.org/node/367118
More info on the node_load static cache issue: https://drupal.org/node/398428

I've turned the solution of reptilex into a patch which fixes the issue.

Corrected path in patch file.

We still don't have the steps to reproduce the issue.

And on top of this, I don't understand how the tnid field is not updated if we are not touching that field and it shouldn't be changed by a simple node edition.

This is why that line was changed btw, #1964006: Don't use $reset flag with node_load()

I observed the same problem. Procedure to reproduce the bug is very simple. The error occurs only when you try to add a new translation of existing content that was previously configured to synchronize the fields. New translations added from the Translate tab are thrown into a new set but the source node is still outside this set. The problem does not occur when disabling the Synchronize translations module and patch included by rterrein in post #6 solved this problem for me. It should be considered in the next release or please prepare some other solution.

@lwalec,

The error occurs only when you try to add a new translation of existing content that was previously configured to synchronize the fields.

Thanks, that is valueable information. Then we only need to properly handle this case.

I had the same problem with 1.10.
For people searching Google who know nothing about tnid's:

" Node translation not working",

Changed the code as stated in patch #6 (as the patch doesn't work with 1.10):

     // Load full node, we need all data here.
-    $translation = node_load($translation->nid);
+    $translation = node_load($translation->nid, NULL, TRUE);
     $i18n_options = i18n_sync_node_options($node->type);

and the problem went away.

#6 corrected bug here too.

See #8, the linked issue, about why #11 is not a solution (may fix this one but has serious side effects)

This problem occured when I had "Entity cache" module enabled. When I disable it, then the translation works. You need to clear the entity cache for the affected nodes when the translation is added. For me it had nothing to do with synchronization. I added a callback for when the translation is submited and cleared the corresponding node cache. That did the trick.

Finally.... So it is Entity cache then, and that's why we couldn't reproduce the issue easily. Updated title.

I have the same problem and "Entity cache" is not installed.
#6 correct bug for me.

+1 #16

The issue exists without entity cache. I had a list(string) field synced.

#6 did the trick for me

@Marc-Antoine,
Before changing the title please find/post steps to reproduce with a clean install. Otherwise let's keep it like that.

The patch in #8 works for me. I don't use Entity Cache (so that may be a red herring). I don't know if it is still required but I think these steps will work from a clean install (my install isnt exactly clean ...)

1. Install i18n, making sure i18n sync is enabled.
2. Add another language
3. Open up the Page content type and under the publisher options enable multilingual with translation.
4. To see it work correctly, just open another window, create a Page (make sure you set your language field), then hit Translate and hit 'add' on your second language. Once the translated page is created click "Translate" again and you will see that they are both linked together.
5. To now easily break it, go back to the Synchronization options on the Page Content Type config screen and enable, say, "status" (could be anything).
6. Now repeating Step 4 will produce the issue outlined in this bug report. Your two nodes are not glued together.
7. To fix it, apply the simple patch in #8. Repeating Step 4 now produced glued together nodes.

Per Jose Reyero's response in #15, I have re-rolled the patch to flush only the necessary node from cache. Fixes the bug for me.

Changing to 'Needs review' to let tests run.

I reproduced the issue following the steps in #22. I don't have Entity cache installed, the bug is independent.

Patch in #24 applies on latest 7.x-1.x-dev and fixes the issue.

Committed. Thanks.

Oh yea, thanks for that!
I was going crazy, all our newer project suffered from this bug, dug into it, found out that it was about the tnid set to 0.
Went over several tickets where this discussion with entity cache is, but we don't use it.

This solved the problem for me! Looking forward to have a new release of i18n, this one is quite an issue in my eyes... at least if you use i18n sync...

I will add this ticket here as related issue, so the other will be noted about this one.
Note: Am I allowed to change the title? This has nothing to do with "entity cache" module, this is just the "entity" module (we are not using entity cache module). Updated also the summary to reflect the latest state of this fixed issue.

updating the title, as this issue has nothing to do with the entity cache module.

Even though I am using version i18n 7.x-1.11 where the patch #24 has been implemented (I double-checked in i18n_sync_node.inc), after adding the translation, 'tnid' is still set to '0' in my database table 'node'.
If I update the requested 'tnid' in the database manually all works fine - but, it's only a temporary solution.

Anybody still facing the issue? I guess it needs more review.

We're definitely still seeing this.

I want to share my experience with a similar issue: translating a node via 'add translation', but tnid is no longer updated in the database.

The site uses i18n_sync. It does not use entitycache.
This site has a custom module with an implementation of hook_node_grant(). The problem started when the function node_load() was used in the implementation.

After removing node_load() everything went back to normal.