Posted by Merlin on Tue May 23, 2006 8:38 pm.
Had a nice chat with someone on IRC today, who was looking for a nice publishing mechanism in Drupal. And my previous article on the topic covered many of the bases quite nicely.
Except for revisions.
Ahh, and that’s something that is quite necessary in a proper publishing workflow, and we can’t currently do that because nodes can’t really have two states.
However, after brainstorming about it, I came up with a plan. One that I don’t have time to execute unfortunately, but I’m putting the plan down so that maybe in the future I can get back to it, or maybe someone who feels strongly about htis will give it a shot. I think if I were to do it it would only take me a few hours. It’s a lot simpler than I thought it would be.
- First, we need a method to clone a node. That’s really really easy: $node = node_load($nid); unset($node->nid); node_save($node); Bonus points: We have to unset the workflow state too. Also, we need to record the nid somewhere, because this node might actually replace the original node.
- Second, we need an action that detects if the node is a cloned node. If it is, it copies the node over the original (again, easy: $node->nid = $old_nid; node_save($node); It’s an action so that we can trigger it when the cloned node is published.
- Third, we need some UI goodies so that we can do nice things like: get a list of clones of a node. Be alerted that the node we’re working with is a clone (working draft) of an existing node, and be pointed to it.
Actually, that’s it. It seems reasonably elegant. There may be some issues in the cloning process that I haven’t thought about that could cause complications, especially with plugin modules. Especially for modules that expect their state to be very different during node/add than node/edit. Could be very interesting to see.
Cloning.. ugh
I don't think that the answer to properly handling revisions is to introduce node cloning. That will only result in an unmanageable mess of duplicate nodes! What we need is the ability to create a new revision as a 'draft', and to properly support this with something like an 'updated revisions queue'. See http://drupal.org/node/48731 - this has been discussed and a patch is already in development.
I think
I think that
http://drupal.org/node/48731#comment-72446
is still a more proper solution. You just need to keep track of what you are doing in a separate table.
Cloning != bad
I have to disagree with the other positions. I think cloning is the way to go.
The node revision table is too limited to be useful. For example, taxonomy terms are not saved in the revision table. I think the only way to make sure that every possible nodeapi added data is captured is to clone.
Revisions vs Cloning
It seems likely to me that a proper revisioning system may be better. After skimming the issue killes linked, I came up with 3 observations:
1) Such a thing requires a core patch, whereas this does not. What this means is that this method could be used in 4.7; things that require a core patch will never be used in 4.7. At the very least, the cloning method would still be useful as a stop-gap until a better revisions system works.
2) As mfrederickson says, revisions are still limited in what data they can have per revision, whereas a clone can be completely different.
3) Clones are no less manageable than revisions. In fact, I think clones are likely to be more manageable than revisions. The revisions will pile up in your database and right now there simply isn't a way to clone up old revisions. Clones, at least if you're using them with my prior publishing system code, will show up in the author's draft pool and one would hope that an author would clean up old drafts in order to keep that page useful to him or her.
no clones
i'm a little uncomfortable with the clones idea too.
the fact that taxo terms don't stay with revision is a simple decision of the taxonomy module. it could maintain its own history, like book module does. you will an open issue on this. when we first implemented revisions it was a 80% solution. the remaining 20% is still outstanding. help wanted.
Post new comment