Posted by soupp on January 28, 2009 at 9:58pm
| Project: | Node clone |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hi guys,
I was not very deep into the problem yet, but: (so beloved) node_clone module may have unpredictable cloning results and may cripple nodes and translations if you use it with i18n. The behavior is about the same in 5.x and 6.x branches. I've had this issues on few different installs (fresh and upgraded).
I just feel it would be nice to make a note about that on module's page. Something like "Warning: not recommended together with internationalization (i18n) module due to unpredictable translations behavior in certain circumstances".
Comments
#1
ok
#2
What sort of problems did you run into? I'd really like to be able to use this with i18n enabled, so I'd be glad to help track this down.
#3
The main problem was: when you create a cloned node it is recognized by i18n as new translation (of the same language sometimes!). But then you could not chose the next language to translate to (in i18n logic it was done already).
Then if there were the menu item with this node it would sit in the db even after cloned node deletion. So if you will go with translation (but not cloning) the menu item would clash with previously created (which then may unpredictably show up or not).
There were some more. The worst in my situation was that I even could not find a pattern for problem. The project was pretty urgent.
#4
Anybody did any further investigation on this subject? I might be need to look at this as well and worth knowing any findings in advance.
#5
Sounds like in D6 at least the tnid needs to be nulled out?
#6
I'm also interested in your experience with this combo.
#7
subscribing, and will invstigate...
#8
Any news looks like we want to use this module on a multilingual web site
#9
My wildest guess would be, as pwolanin pointed out, to do this in clone.pages.inc in function clone_node_prepopulate after 115:
$node->tnid = NULL;no more weird translation issues should arise
#10
Lets have a more descriptive title for this.
#9 sounds reasonable to me; I see no reason why cloned nodes should have a translation set.
#11
anyone tested yet ?
#12
Here is an untested patch that should hopefully do the trick. @harrrrr, it would be great if you could test it.
#13
subscribe
#14
Got confusing results too. But testing showed the crux of the matter: when creating a duplicate of a node that has a translation the translation is taken into the new duplicated node too. So as the result there is the original node and the duplicated and each of them are concatenated to the same translation. So you'll overwrite the translation of the one node if you are changing it for the other.
So the solution is to disconnect the translation when cloning a node.
This works in my environment by changing the modul code as follows:
node_clone/clone.pages.inc:
function clone_node_save($nid):
within
if (isset($node->nid...add:$node->tnid = NULL;e.g. below
$node->nid = NULL;If you even want to clone the translation when cloning a node - that would be another story... ;-)
But in the mentioned way you get no more failure and node mismatches at least!
This is a non-binding hint...(!)
#15
patch works for me.
#16
We need an actual patch please.
#17
#18
#19
Looks basically fine - probably we don't even need the isset.
#20
committing this patch.
#21
Automatically closed -- issue fixed for 2 weeks with no activity.
#22
This means that the issue is completely fixed? If so, why is still the warning in the description page of the module?
#23
Can we use i18n and node clone now?.
Regards,
#24
#25
Viewing the source of the latest stable release, I see the patch in #20 is now included. And from my initial tests, it seems to work OK with a multilingual site I'm currently working on.
As this issue appears to be fixed, please can this issue be closed and the warning notice removed from the module homepage.
Thanks
#26
#27
Automatically closed -- issue fixed for 2 weeks with no activity.