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".

CommentFileSizeAuthor
#20 365797-tnid-19.patch864 bytespwolanin
#17 node_clone-365797.patch634 bytesrapsli
#12 365797_null_tnid.patch608 bytesdeviantintegral

Comments

pwolanin’s picture

pwolanin commented

ok

deviantintegral’s picture

deviantintegral commented

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.

soupp’s picture

soupp commented

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.

hanoii’s picture

hanoii
Primary language Spanish
Location 🇦🇷UTC-3
commented

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.

pwolanin’s picture

pwolanin commented

Sounds like in D6 at least the tnid needs to be nulled out?

perandre’s picture

perandre commented

I'm also interested in your experience with this combo.

asak’s picture

asak commented

subscribing, and will invstigate...

deverman’s picture

deverman commented

Any news looks like we want to use this module on a multilingual web site

eikes’s picture

eikes commented

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

deviantintegral’s picture

deviantintegral commented
Title: so bad i18n issues » Node clone might not be compatible with i18n translation
Version: 6.x-1.0 » 6.x-1.x-dev

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.

harrrrrrr’s picture

harrrrrrr commented

anyone tested yet ?

deviantintegral’s picture

deviantintegral commented
Status: Active » Needs review
StatusFileSize
new 365797_null_tnid.patch608 bytes

Here is an untested patch that should hopefully do the trick. @harrrrr, it would be great if you could test it.

momper’s picture

momper commented

subscribe

anfrage’s picture

anfrage commented
Version: 6.x-1.x-dev » 6.x-1.0
Component: Miscellaneous » Code
Priority: Normal » Critical

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...(!)

rapsli’s picture

rapsli commented
Status: Needs review » Reviewed & tested by the community

patch works for me.

pwolanin’s picture

pwolanin commented
Version: 6.x-1.0 » 6.x-1.x-dev
Status: Reviewed & tested by the community » Active

We need an actual patch please.

rapsli’s picture

rapsli commented
StatusFileSize
new node_clone-365797.patch634 bytes
pwolanin’s picture

pwolanin commented
Status: Active » Needs review
pwolanin’s picture

pwolanin commented

Looks basically fine - probably we don't even need the isset.

pwolanin’s picture

pwolanin commented
Status: Needs review » Fixed
StatusFileSize
new 365797-tnid-19.patch864 bytes

committing this patch.

Status: Fixed » Closed (fixed)

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

sapox’s picture

sapox commented

This means that the issue is completely fixed? If so, why is still the warning in the description page of the module?

un11imig’s picture

un11imig commented

Can we use i18n and node clone now?.

Regards,

un11imig’s picture

un11imig commented
Status: Closed (fixed) » Needs review
edward.kay’s picture

edward.kay commented

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

pwolanin’s picture

pwolanin commented
Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

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