The purpose of this patch is to enable a copy operation on nodes.
The semantics of this are: given a node, a copy is saved. Only
the title is changed (and of course the node will have new nid).
Hence, for example, copies of book pages are siblings of the
original.

Q. Are there any situations where having a copy of a node
will mess up a compound/structure?

Q. Should anything else be modfied (created/changed dates, ...)?

Could you please review carefully - I'm pretty new to this
code! Please pay special attention to:

- permission checks - I'm not clear on the semantics of these
- generation of watchdog entries / messages

The patch makes the following changes:

1. Adds a function node_copy(&$node), based on node_submit. This
accepts a node or node array, and checks if the current user has view
permissions and create permissions. If so, it creates a title

"(Copy of node ".$node->nid.") ". $node->title

It then clears the node's nid, and submits to node_save(), which
creates a new node. Appropriate messages are generated to indicate
success or reasons for failure.

2. Adds an item to the $items[] array in node_menu after line 710 to
allow adding copying a node '$nid' by by "node/$nid/copy". This tries
to follow the way "node/$nid/delete" is handled.

3. Adds an operation

'copy' => array(t('Copy the selected posts'), ''),

(at line 748) to the operations array in function node_admin_nodes()
to allow mass copying of nodes (a la mass deletion of nodes).
Implements this operation.

4. Adds a case in function node_page() to take care of the copy
operation.

CommentFileSizeAuthor
node_copy_patch4.06 KBpuregin

Comments

syscrusher’s picture

syscrusher commented

Just a question...

How does what you propose differ from the EditAsNew module?

http://drupal.org/node/16806

Just curious.

Scott

puregin’s picture

puregin commented

Hi Scott,

This implements copy at the level of nodes, which feels
right to me. That EditAsNew exist illustrates the need
for this functionality. To me, having to implement this
outside of node.module is awkward and leads to potential
problems with concurrency.

Putting this in node.module also enables mass copying
of nodes, which seems like a useful thing to be able to
do. It also exposes copying in a more programmatic
way.

Modules which would like to support making copies
could offer this to users by generating a link.
This is parallel to the 'Add child' link functionality
presented by the 4.6 version of book.module.

On the other hand, EditAsNew has some nice design
ideas also - being able to selectively copy fields
might be useful. Some users might prefer to see
this operation expressed as a tab. It seems like
it should be possible to simplify EditAsNew based
on a copy function in node.module.

Regards, Djun

syscrusher’s picture

syscrusher commented

Thanks, Djun, for the detailed reply. I understand better now.

Bèr Kessels’s picture

Bèr Kessels commented

A quick scan of the patch and your desciption:
* always use two spaces for identation
* try to avoid the use of words such as "items"
* never use the word "node" or show node ids to users, they are developers stuff, not meant for users.
* you add an awfull lot to the watchdog, IMO.
And last but not least: do we really need this? I would vote against this functionality in core, this should really live in editasnew.module (not even a new copynode.module).

Bèr Kessels’s picture

Bèr Kessels commented

O, and thanks for taking the time to make a patch. I never meant the above post to be rude, just as some guidelines to help you make even better patches :).

killes@www.drop.org’s picture

killes@www.drop.org commented

I agree with Ber: If it can be done through a contrib module it shouldn't be in core.

dries’s picture

dries commented

Until there is a strong demand for this functionality, I won't add this to core. I checked and the 'editasnew' module has been downloaded 250 times the past month compared to 20k downloads for Drupal.

Kieg Khan’s picture

Kieg Khan commented

Hello,

As I read it, copyasnew is designed to create a new node with automatic filling of (selective) fields based on a previous node, while nodecopy is designed to copy a whole node directly. Also, copyasnew would appear to have problems with other node types such as flexinode (which might be fixed by now), whereas it would seem that nodecopy is independant of the node type.

If you wanted to create a workflow that could create a duplicate node which would be used in place of the original node while it is being edited, would copyasnew be able to do that, or would it rely on intervention from the user?

Finally, if the cost of adding this functionality is not too great, then why leave it out? I am sure there are plenty of areas of Drupal that do not get used very much, but are there never the less. If you look at Drupal in a similiar light to an operating system, then there are basic create, copy, rename, delete functions. Drupal already has create and delete, so copy is a logical extension to these features. If it is not there, then nobody can use it. If it is there, then just possibly unknown uses will be found for it.

Thanks.