On my site I want users to able to clone and make their own versions of nodes, but I also want users to be able to see what derivatives have been made. For example, a block that shows what other nodes were made by cloning the viewed node. Then users could click into that block to see the clone, and what clones have been made of it.

I see this as requiring two chunks of work:
1) Make and update a table such as {clone_relation} that pairs parent and child clones.
2) Make a block that displays clones for the viewed node.

Does anyone else have use for this? If a patch is submitted for it, how inclined are the maintainers to commit it?

CommentFileSizeAuthor
#5 clones_history.zip4.46 KBeikes
#3 clones_history.zip2.22 KBeikes
#1 clones_history.zip1.68 KBturadg

Comments

turadg’s picture

turadg commented
StatusFileSize
new clones_history.zip1.68 KB

Since not everyone will want the tables necessary to keep track of this, I made it a separate module that can be installed and uninstalled. It makes use of the handy clone_node_alter hook.

I've attached the whole module as a ZIP.

Unfortunately, it's not working yet for the 'prepopulate' method of cloning because the clone ids aren't known at prepopulation time and the original ids aren't known at node save time. For the 'save-edit' method, I added a property, 'clone' array, to the node, but it gets lost through the edit form.

If anyone has any advice on how to make 'prepopulate' work, I'd appreciate it. Maybe something with a form alteration?

pwolanin’s picture

pwolanin commented

You should be able to use the alter hook to copy the nid onto the new object, though really this would not be a big deal to include in the main module. In any coase there is some code duplication that should be reduced. I think you would then need a form_alter in the prepopulate case in roder to propagate the data through from the form to the node_save().

eikes’s picture

eikes commented
StatusFileSize
new clones_history.zip2.22 KB

I enhanced the module clones_history so that it also works for the prepopulate method.

I added some code, to have the clones_history information available when a node is loaded. I also added some code to show this information.

eikes’s picture

eikes commented

just figured it is indeed nicer to have it as a block, like turadg asked for, so i did that. New Version is attached and if you don't want a block, but want to put the info in the node body you can still insert in it your node template by calling:

<?php print theme('clones_history', $node); ?>

obviously you can override the theme function by creating phptemplate_clones_history($node) in your template.php

I would guess that it would be a good idea to put this module in the node_clone folder so it gets distributed with the clone module but you have to activate it seperatly. Or merge the code with the clone modules code. either way...

eikes’s picture

eikes commented
StatusFileSize
new clones_history.zip4.46 KB

sorry, forgot the attachment...

pwolanin’s picture

pwolanin commented
Status: Active » Closed (duplicate)

duplicate to #654508: Add a way to determinee that a node was a clone

physiotek’s picture

physiotek commented
Status: Closed (duplicate) » Active

Eikaa,
thanks for the block.
but i have a little request...
let'S say i have nid 315 which is a clone of nid 310
and nid 310 is a clone of nid 305.
when i look at node 315 i can see a link to node 310 as the parent.
but i would like instead a link to the 'master'... 305
is there a way i can acheive this?
thanks!

thedavidmeister’s picture

thedavidmeister commented

I think this is a great idea is it could enable building a lot of powerful functionality in the future, like editing "parent" nodes with the option to propagate the changes to all "child" nodes at save time.

thedavidmeister’s picture

thedavidmeister commented

@pwolanin - This thread seems to be closer to a solution and is older, so really #654508: Add a way to determinee that a node was a clone would be a duplicate of this thread. Regardless, this thread is for functionality that records ancestor nodes permanently in a separate table so they can be viewed and referenced later, whereas the other thread is literally just for the creation of a hook that temporarily lets the system know that the new node is a clone of the old clone - this information is lost as soon as the clone is saved.

pwolanin’s picture

pwolanin commented
Issue summary: View changes
Status: Active » Closed (won't fix)

The use cases and needs for this are pretty variable, so I don't think it should be part of the base module.