I have my default settings for most node types set up to publish the nodes immediately. However when I clone a node, I don't want it to be published immediately, because I usually need to edit it a bit before it's ready to "go public". This patch (for 4.7) adds extra checkboxes to the settings page to allow cloned nodes of a given type to be NOT published.
This overrides the publishing setting regardless of the default settings for the node type.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | prepopulate_clone_5x_3.patch | 4.38 KB | pwolanin |
| #15 | prepopulate_clone_5x_2.patch | 3.98 KB | pwolanin |
| #8 | prepopulate_clone_1.diff | 2.86 KB | pwolanin |
| #7 | clone.module | 3.29 KB | pwolanin |
| clone-publishing.patch | 1.34 KB | jjeff |
Comments
Comment #1
jjeff commentedgood point
Comment #2
jjeff commentedDoh!
Ignore that last post.
Comment #3
pwolanin commentedMaybe this should be generalized more to include moderated, demoted, etc.?
Also, there is already an option to reset the publishing options upon cloning- is your content type set to published or unpublished by default?
Comment #4
jjeff commentedMy settings for this node-type are set to default to published -- as is the case with most of my node types.
The problem: I can't imagine why *anyone* would want a node entitled "Clone of [Name of Content]" to appear live on their site for any amount of time. They will usually edit the clone and update the content... maybe a new date for a new workshop... maybe a new location for a different store... whatever. But if an RSS reader comes along while they're editing, it'll pick up "Clone of [Name of Content]". Not cool.
The truth is that the node shouldn't be saved into the database when it is cloned. It should simply populate the node editing form as a new node... and then save (for the first time) when the form is submitted. I'm not sure how practical it is to do this though. I've had really good luck using this module to clone items like WebForm nodes and it works fine. I doubt that it would work without actually cloning the node object and running it through node_save() before editing.
Comment #5
pwolanin commentedYes, I was thinking recently about possibility of populating the form instead of saving the node first. Of course, saving the node first doesn't always work either.
I understand your concern, and I'll look more at the patch.
Comment #6
jjeff commentedPerhaps a better solution is to clone ALL nodes as unpublished (so they're not live) and then do a form_alter() on the editing form to set it up with the default values as set for that node-type. This way you could remove *all* of the settings for the module -- except for the confirm setting I guess...
That would be kinda nice actually. :-)
Comment #7
pwolanin commentedTry this- a different version of the module for 4.7 (whole module attached followed by a patch)- it just pre-populates the node form, rather than saving to the DB first. Haven't tried it with any complicated nodes yet, but it works for simple ones and avoids the temporarily bad content issue.
Comment #8
pwolanin commentedin patch form vs. 4.7
Comment #9
joestewart commentedThanks for the patch to only prepopulate the form. This works much better for my 4.7 site. I was having errors with nodes that have attachments. upload_image module spit out this error:
No problems while testing this patch.
Comment #10
anders.fajerson commentedI tried the patched module with the Advanced Poll module which has a pretty advanced node form (where this module could be a real timesaver).
In my limited testing it worked without errors (the 4.7.x or 5.x release does not work for all fields). Any plans on releasing this version for Drupal 5? To me this seems like the right approach to clone a node. Great work.
Comment #11
pwolanin commentedYes, I'll do it for 5.x sometime soon. My only question is whether to continue both versions for 5.x and beyond?
Comment #12
pwolanin commentedfixing title
Comment #13
pwolanin commentedComment #14
anders.fajerson commentedPersonally I don't see any benefits of doing it the old "DB" way, if that was what you asked for.
Comment #15
pwolanin commentedHere's a patch for 5.x- works with OG at least, in addition to simple node types. I'll have to look at the 4.7 patch again to see if I'm setting the form ID correctly.
Comment #16
pwolanin commentedThis one might be better- also unsets the list of file attachments to prevent a false listing in the node form.
Comment #17
anders.fajerson commentedPatch (5.x) applies and works with advanced poll forms.
Just a small thing: most modules use the same project/folder/file-name, this one uses both node_clone and clone. Might be a thing for the stable 5.0 release.
Comment #18
anders.fajerson commentedOne more thing: I see that you removed some settings. But isn't the publish option also redundant with the non-db approach? Would be sweet without a settings page.
Comment #19
pwolanin commentedsomeone else had the "contributions/modules/clone" when I started this, so the discrepancy has been there all along.
The setting is to reset the publishing options (e.g. promoted, sticky etc), so I think it's a needed feature still. Imagine you let a non-admin clone nodes- they clone one on the front page, but you might not want their new post to also be on the front page without your approval.
Comment #20
anders.fajerson commentedI see. How about making that the reset behaviour default for users without admin permission and just provide a "Note: Publishing options has been reset"? No settings. Just an idea. Maybe there are cases where you really want the publishing options to stick...
Comment #21
pwolanin commentedI committed the 2 patches to the DRUPAL-4-7--2 and DRUPAL-5--2 branches- so you can pull those out of CVS if you want to test the module in "pre-populate" mode (e.g. "$ cvs co -r DRUPAL-5--2 contributions/modules/node_clone").
Comment #22
anders.fajerson commentedDid that. I did expect an updated Drupal-5 branch though. Anyway, this release is great, thanks again.
Comment #23
jjeff commentedPlease test this with webform nodes. Node-types don't get much more complex than that... and you actually have to go to a separate page to edit form fields... The "old" method works just fine for these nodes, but I'm nervous that this new method won't. I haven't had a chance to test this yet though...
Sorry for the incomplete critique.
Comment #24
hass commented@pwolanin: please support 4.7.x for a while. For me - i cannot change to 5.x today while there are so many modules not upgraded, ready or buggy for 5.x :-(
Comment #25
hass commented@fajerstarter: do you like to change the filename "clone.module" to "node_clone.module", too? i'd like to see this fixed, too.
Comment #26
pwolanin commented@haas - this is a simple enough module that I'll fix any bugs in any of the 4 current versions (2 for 4.7.x and 2 for 5.x)
Comment #27
pwolanin commented@jjeff - a quick test with DRUPAL-5 webform and the DRUPAL--5-2 version of this module seems to work fine.
Comment #28
leoklein commented+1 for switching to pre-populating the form. I come to Clone after using 'Edit as New' for quite a while and this seems more intuitive.
Thanks.
Comment #29
pwolanin commented@patachon - this is available as the 5x.-2 branch on the download page- please provide any feedback on the functionality.
Comment #30
(not verified) commented