Save revision as draft feature

I don't think the last patch makes a lot of sense. :p

I think your aim can be reached without a patch.

If there is an already existing revision, the node object will have a property old_vid. In the update hook you could check this and if it is also a draft revert the current vid back to the old vid.

I am investigating Drupal as a potential solution for an upcoming CMS project. I apologize if this is not the correct place to post this question.

In the scenario of the website I will be creating, all pages and posts will be published from day 1 that the site goes live. After this, users will be making edits to the published content on a regular basis. However, there needs to be workflow around this revision process. For example, if a user makes a revision to some existing published content, this change should not 'go live'... it should be added as a 'proposed revision'. Then, an administrator would come along and accept or reject this revision.

I have been searching through this site for a few hours and have installed and reviewed the workflow module, which seems to accomplish part of what I need to do. This patch seems as though it may accomplish the rest; that is, to allow a user to create a draft revision without publishing it.

Are there any other threads, patches, modules, etc that would help me to accomplish the above goals? General advice? Thanks!

just a question:
is it possible with this patch that the user edits a node (and creates a new revision) and this revision goes into the moderation queue and the old rev stays active and online (does not go into the moderation queue - and therefore gets NOT hidden on the site)?
it this is the case then definitely +100000000

I dont understand node_draft.patch, do I need this and the first patch?
and there gets db_query($node_query, $node_table_values); called twice... is that right?

This is exactly what I want to do, but it doesn't seem possible, see my thread...

http://drupal.org/node/50506

I haven't tried that patch to the CVS version, but sadly this is a production site and I can't use a CVS version. I tried the patch for 4.7 beta but I couldn't get it to work. If you find a solution I would be VERY grateful if you would let me know!

I am all for making a variety of workflows available wrt revisions. However, it is now a bit late for 4.7. The revisions patch lingered in the patch queue for over a year and wasn't really looked at by many people when it was time to make suggestions for improvements.

This seems to be trying to accomplish the same as http://drupal.org/node/38451
I would really like to see drumms patch get in.
The revert to unpublished behavior is annoying.

I have been trying to get this patch installed... what version of Drupal does this work with? I notice it says CVS -- but isn't the CVS always changing?

Hi Edrex,
Well done. I have been looking for a drafts module for a long time now and had posted an idea to use the revision.module elsewhere. I loaded your patch node_revs into my 4.7.0b5 installation and it works, not quite as I expected, but definitely usable.

In my node.module there is this code:

$node_options = variable_get('node_options_'. $node->type, array('status', 'promote'));
  // If this is a new node, fill in the default values.
  if (!isset($node->nid)) {
    foreach (array('status', 'moderate', 'promote', 'sticky', 'revision') as $key) {
      $node->$key = in_array($key, $node_options);
      // Don't show node options if the user doesn't have admin access.
      $form['options'][$key] = array('#type' => 'value', '#value' => $node->$key);
    }
  }
  $form['#node']   = $node;

and in your patch there is this code:

   $form['created'] = array('#type' => 'value', '#value' => $node->created);
   $form['changed'] = array('#type' => 'value', '#value' => $node->changed);
   $form['type']    = array('#type' => 'value', '#value' => $node->type);
-  $form['#node']   = $node;
+  $form['draft']    = array('#type' => 'value', '#value' => 1);

I applied the patch, all but this code as I do not know how the two equate. As far as the second node_draft patch, I did not try that, but I think I can see what that would do and maybe it would be better for my purpose, I will see.

Anyway, this code should be examined by any Drupal core developers and implemented ASAP. Drafting is sorely missed and much needed.
Thanks.

Hi Edrex,
I applied the node.draft patch and it did not work on my system. It gave an SQL error that there was a duplicate id in the node_revisions module, but the node_revs patch works apart from the difference in code in my previous post.

Some feedback (and the lack of the previous code might explain). When the admin creates the content, they can edit any revision (not sure I like that, they should only be able to edit future revisions, ie drafts, I think).

In the permissions, there is no option for edit revisions, so I can give a user permission to publish a revision, but they can only edit the published revision. Can this be done? It would be important for the user to be able to edit the (future) revision as well.

It can be worked around because the user can publish their draft, work on it and then publish the current revision. There is a slight chance that a site visitor will see the draft document as the current revision during these movements of the document.

There are a few other little issues such as when the user edits the document they create another revision, so the admin user needs to do a bit of work to prevent this.

Finally, do you have any thoughts on how to workflow any of this? In my site the new revision becomes the current revision automatically, yet in reading your post I got the impression that the node.vid should retain the previous value forcing the new revision to effectively become the draft.

Not a big problem, but any manual process is prone to errors.
Thanks.

Hello edrex,
Further to the previous post, the only place I can find anything close to the code in your node_revs patch in 4.7.0b5 is this code:

/**
   * Basic node information.
   * These elements are just values so they are not even sent to the client.
   */
  foreach (array('nid', 'vid', 'uid', 'created', 'changed', 'type') as $key) {
    $form[$key] = array('#type' => 'value', '#value' => $node->$key);
  }

I changed this code to:

  /**
   * Basic node information.
   * These elements are just values so they are not even sent to the client.
   */
  foreach (array('nid', 'vid', 'uid', 'created', 'changed', 'type', 'draft') as $key) {
    $form[$key] = array('#type' => 'value', '#value' => $node->$key);
  }

and as far as I can tell it made no difference to the running of the web site.
Thanks.

I applied this patch (by hand unfortunately) to the latest CVS version with no apparent change in functionality. It looks like the code in the node.module has changed significantly in several of the places that this patch applies to. Is there a more recent version of this patch that will work with the recent beta and/or cvs versions?

Hello,

I have applied the patch to my 4.7.0beta6 install and apart from the post previously, it has worked as the same as it did in 4.7.0beta5.

Regards.

Hello,
Sorry I cannot create the correct diff file, but using edrex's node_revs.patch make the following changes:
Instead of this,

@@ -1628,7 +1660,7 @@
   $form['created'] = array('#type' => 'value', '#value' => $node->created);
   $form['changed'] = array('#type' => 'value', '#value' => $node->changed);
   $form['type']    = array('#type' => 'value', '#value' => $node->type);
-  $form['#node']   = $node;
+  $form['draft']    = array('#type' => 'value', '#value' => 1);

use this,

  /**
   * Basic node information.
   * These elements are just values so they are not even sent to the client.
   */
-  foreach (array('nid', 'vid', 'uid', 'created', 'changed', 'type') as $key) {
-    $form[$key] = array('#type' => 'value', '#value' => $node->$key);
-  }
+  $form['nid']     = array('#type' => 'value', '#value' => $node->nid);
+  $form['vid']     = array('#type' => 'value', '#value' => $node->vid);
+  $form['uid']     = array('#type' => 'value', '#value' => $node->uid);
+  $form['created'] = array('#type' => 'value', '#value' => $node->created);
+  $form['changed'] = array('#type' => 'value', '#value' => $node->changed);
+  $form['type']    = array('#type' => 'value', '#value' => $node->type);
+  $form['draft']    = array('#type' => 'value', '#value' => 1);

As I keyed these changes by hand, I do not know the correct diff process, so if someone can create the diff file from this, then that would be great.

Everything else in edrex's file appears to do the right thing.

Note: If you do not make the above code changes, then the effect when editing a revision is that the edited revision becomes the published content and you need to manually go to revisions and publish the actual revision you want your site visitors to see.

With the above code, when you edit a revision it will not update the published information, so the revision the site visitors see is what ever revision was published, not the revision that has been edited.

I think this patch is very good, but I will be working to create it so that past revisions cannot be edited, only future revisions. This would satisfy audit requirements for many sites. As it is at the moment you could change historical data, which is not what would be intended.

Thanks.

Sorry, there was a mistake in the previous post.

   /**
   * Basic node information.
   * These elements are just values so they are not even sent to the client.
   */
- foreach (array('nid', 'vid', 'uid', 'created', 'changed', 'type') as $key) {
- $form[$key] = array('#type' => 'value', '#value' => $node->$key);
- }
+ $form['nid'] = array('#type' => 'value', '#value' => $node->nid);
+ $form['vid'] = array('#type' => 'value', '#value' => $node->vid);
+ $form['uid'] = array('#type' => 'value', '#value' => $node->uid);
+ $form['created'] = array('#type' => 'value', '#value' => $node->created);
+ $form['changed'] = array('#type' => 'value', '#value' => $node->changed);
+ $form['type'] = array('#type' => 'value', '#value' => $node->type);
+ $form['draft'] = array('#type' => 'value', '#value' => 1);

The last line should be:

   /**
   * Basic node information.
   * These elements are just values so they are not even sent to the client.
   */
- foreach (array('nid', 'vid', 'uid', 'created', 'changed', 'type') as $key) {
- $form[$key] = array('#type' => 'value', '#value' => $node->$key);
- }
+ $form['nid'] = array('#type' => 'value', '#value' => $node->nid);
+ $form['vid'] = array('#type' => 'value', '#value' => $node->vid);
+ $form['uid'] = array('#type' => 'value', '#value' => $node->uid);
+ $form['created'] = array('#type' => 'value', '#value' => $node->created);
+ $form['changed'] = array('#type' => 'value', '#value' => $node->changed);
+ $form['type'] = array('#type' => 'value', '#value' => $node->type);
+ $form['draft'] = array('#type' => 'value', '#value' => $node->draft);
+  $form['#node']   = $node;

and it seems that

  $form['#node']   = $node;

is optional.

When the $form['draft'] was 1 then no new content could be created. This fixes that issue and still allows editing revisions without promoting those edits to the current published state.

It would be nice if anyone could explain what this bit of code is doing, and it would also be nice if past revisions could not be edited unless they were set to published first.
Thanks.

Updated patch compatible with CVS attached.

I modified the troublesome section above:

- foreach (array('nid', 'vid', 'uid', 'created', 'changed', 'type') as $key) {
- $form[$key] = array('#type' => 'value', '#value' => $node->$key);
- }
+ $form['nid'] = array('#type' => 'value', '#value' => $node->nid);
+ $form['vid'] = array('#type' => 'value', '#value' => $node->vid);
+ $form['uid'] = array('#type' => 'value', '#value' => $node->uid);
+ $form['created'] = array('#type' => 'value', '#value' => $node->created);
+ $form['changed'] = array('#type' => 'value', '#value' => $node->changed);
+ $form['type'] = array('#type' => 'value', '#value' => $node->type);
+ $form['draft'] = array('#type' => 'value', '#value' => 1);

to:

foreach (array('nid', 'vid', 'uid', 'created', 'changed', 'type') as $key) {
  $form[$key] = array('#type' => 'value', '#value' => $node->$key);
}
+  $form['draft'] = array('#type' => 'value', '#value' => 1);
+  $form['#node'] = $node;

When I set assigned $node->draft to $form['draft'] the latest revision was still being published. However, as long as $node->draft was set to 1, everything worked as expected. I never experienced the problem you were having with no new content being able to be created.

One thing I have noticed with this patch, however, is that it doesn't play nicely at all with the moderation queue. I would expect the most recent revision waiting for approval to be able to go into the moderation queue. I still don't understand how the node.module works well enough to debug this yet or figure out a way for this to happen.

Should've caught this earlier - but I noticed that even users with administer nodes privileges were forced to moderate their own revision. I expected admins to be able to immediately publish a new revision.

I guess the question that needs to be answered is whether or not revisions should always be created as "drafts" for all users or should some users be able to create a "non-draft" (immediately published) revision? Perhaps there needs to be a UI change somewhere ...

Meanwhile, I've updated my previous patch to allow revisions for users with administer nodes privileges to be published immediately without the extra step of going to the revisions tab and clicking "publish." The only additional change was:

@@ -1715,6 +1748,8 @@
  $form['#node'] = $node;
 
  if (user_access('administer nodes')) {
+    $form['draft'] = array('#type' => 'value', '#value' => $node->draft);
+  
    // Node author information

Thoughts? Comments?

Ok, last patch for today I hope. This one just updates my previous patch by:

- Adding the ability for "draft" revisions to respect moderation queue settings. So that a node can show up in the moderation queue when a new, unpublished revision is created.

- Minor UI tweak so that if a instead of "The page was updated.", the user sees "The page revision was submitted for moderation." when a new, unpublished revision of a node is created and added to the moderation queue. That way if a user submits a new revision for moderation, they don't see "The page was updated" when the actual live content hasn't changed yet.

Convince me that I want this in core.

Consider this (what I would consider a fairly common) use case:

A site has a number of authors who can't administer nodes but can edit their own pages. This arrangement allows an editor to assign responsibility of each page to an author who can make changes to their own content but ensures that they can't modify content that they don't own.

Now, say you want to make sure that whenever an author edits a page that the updated content is moderated prior to going live (to ensure consistency, quality, etc.). If the changes are approved by the editor, the updated content goes live. In the meantime, the original content should still be available to the site's users.

This is only partially possible as the moment if you set the default content settings to "unpublished," "in moderation queue," and "create new revision." However, when an author edits a page (with the permissions above and these settings), the page becomes unavailable to anonymous users because it has been unpublished - effectively removing the page from the site until the updates are moderated and republished.

And that's what this patch seeks to fix - to allow a new revision of a node to be moderated prior to replacing existing content, while keeping the existing content available to users in the interim. This patch seeks to modify the behavior of revisions so that when an author under the above scenario makes changes to a page, several things (could/should) happen:

1. The updated content is saved as a new unpublished revision at the top of the revision queue.
2. The original content remains published and accessible to anonymous users.
3. The page is added to the moderation queue so that the editor knows that the page needs reviewing.
4. After review, the new unpublished revision can be approved and published - taking the place of the previous revision.

Hello chx,

I agree with mattgrayson. The biggest problem with Drupal as standard is that unpublished content is entirely invisible to the site visitors, while Published content always refers to the latest revision.

This patch allows the middle ground of allowing existing content to remain Published while a new revision of the content is being prepared.

Thanks.

Hello mattgrayson,

When I changed my code to this value I again experienced problems where Drupal tells me the content was posted but there is actually nothing happening. It was working Ok for a little time, but then suddenly stopped. The last things I was doing was changing and adding Taxonomy Terms, so maybe it has something to do with that?

+ $form['draft'] = array('#type' => 'value', '#value' => 1);

When I changed it back to this it all works correctly.

+ $form['draft'] = array('#type' => 'value', '#value' => $node->draft);

I do not know why this behaviour is not being seen by you so maybe it is my setup:
Windows IIS6
PHP 5.0.4
MYSQL 4.1.11

Also my content is allocated to several Taxonomy Categories.

Thanks.

Hi Kieg Khan,

To be perfectly honest, I have no idea why you're experiencing that behavior with $form['draft']. The only thing I can think of is if there was some change to the node.module between beta6 (your version?) and current cvs version that I've been working off of. Your setup shouldn't have any effect on this, btw.

All that

$form['draft'] = array('#type' => 'value', '#value' => 1);

is doing is flagging the node as a "draft" prior to editing so that when you save the node the proper changes are made to the node_revisions table instead of the node table. And really, I think this setting should be pulled out of the code and placed in the UI as a system/node level setting. As the patch works at the moment, all edits made by users without "administer nodes" privileges are saved as draft. This would probably work better if there was a checkbox under the "Publishing options" of a node to "Save as draft." There should also be a similar option under administer -> settings -> content types -> configure to enable/disable "Save as draft" as default option for a node type.

:-) node.module has changed in cvs (this patch has been committed).
And I think it involves some lines impacted by your patch.

Aside from that :
+1 for the fact that the lack of a "moderate revisions without unpublishing previously approved content" capability (is there a better term ?) is a huge shortcoming in drupal's current revisions management.
I didn't dare raise the priority as 'critical', but I did have the itch...

I do need this, so thanks for the patch, whether it gets committed or not.

Sorry - I goofed that. The commit I was referring to doesn't in fact deprecate your patch.
(it impacts that one, which is (kind of) related)

But my "+1" part remains unchanged :-)

PS : permission 'publish revisions' appears twice in your node_perm hook

The patch has been updated to ensure compatibility with the latest cvs changes to node.module. The code has been cleaned up a little bit; but it's still not perfect or as clean as it could be.

I've also taken the step that I mentioned earlier of incorporating this functionality into the GUI instead of embedding it in the code. The option to "Save revision as draft" has been added in two places:

• one under "administer -> settings -> content types -> configure"
• and the other under "Publishing options" for the individual node

When "Create new revision" and "Save revision as draft" are both checked, the changes are saved as an unpublished revision ("draft") at the top of the revision queue. Same functionality as before - only now it can be enabled/disabled from the node edit and the content-type configuration forms.

When only "Save revision as draft" is checked, no change to functionality occurs - it's just like saving the node without creating a new revision. Ideally it would be possible to disable "Save revision as draft" when "Create new revision" is unchecked. Unfortunately, I haven't figured out how (or if) this is possible with the form API.

Thanks mattgrayson,

I will apply this and see how it goes for me. You seem to have a good grasp of Drupal programming, so there is one other aspect to this patch that is causing me trouble. Currently, to edit the revisions you need to have the permission for Administer->Access Control->Node Module->Administer Nodes. This then fives those users full control over content, which is not a problem in my site but could be a problem in someone elses site.

Do you see anyway to give the possibility for a user to edit their own revisions? This would then let those users work on their draft after it is submitted, but before it is "published"

Thanks.

Hi Kieg Khan,

The ability for a user to edit their own revisions was in the original patch. I took it out, though, because it was rather buggy and I wasn't making any progress in figuring out why. I agree that it would be useful to have that in there. For now, I am just telling users to create another revision if they want to make additional changes. Not ideal. But that's the best I've got until I can track down the bugs :-/

This is a very nice feature. I think even the UI for it belongs in core but I don't care much about that. Book.module currently unpublishes pages when they get edits. Thats absurd. Thgis will patch will allow for revisions ahead of the 'publishded' revision. very useful.

Hello,
This module is working very well now and it would be great if the Drupal authors could commit it to Core.

Anyway, the only thing that is an issue for me now is that once the author has created the draft document they cannot work on it. Only users with Administer Nodes can alter the draft document, which is fine in a small site, but becomes a problem in a larger site.

Thanks.

Hello,

As I am not a programmer, can someone please review this code change (applied to node_rev_gui,patch) and tell me if it is correct?

@@ -585,7 +591,7 @@
  * Implementation of hook_perm().
  */
 function node_perm() {
-  return array('administer nodes', 'access content', 'view revisions', 'revert revisions');
+  return array('administer nodes', 'access content', 'view revisions', 'publish revisions', 'delete revisions', 'edit revisions');
 }

So far in my testing, this change will allow the role that is assigned this permission to edit their revisions. It is not necessary to have the administer nodes permission to make changes to the draft revision.

The only other thing I would like changed would be that only the current and newer than current revisions can be edited. Any revisions older than the current revision should not be able to be edited. When an older revision is published it should cause a new revision to be created from that older revision. These changes are required for auditing purposes.

Thanks.

There's a problem with this patch :
When you edit a node (plain and simple - no draft, no revision) and change its title, the 'title' field is correctly updated in {node_revisions}, but not in {node}.

The admin/node page listing, for instance, still shows the old title for the node.
This impacts the 'Node: Title' fields in table views (views.module) as well, and probably several other places where the node title is retrieved by a direct {node} table query, as opposed to node_load / $node->title.

Looking at the code, I guess the "changed" timestamp in {node} is not updated either (I did not test that)

(Once again, kudos for the drafting functionnality, though)

Hello All,

Updated patch to ensure compatibility with 4.7 RC2. There's also a bug fix for the node.title issue yched pointed out. The node table was not getting updated at the appropriate time - hence, no updated title, timestamp, etc. This update should fix that issue.

Kieg Khan, re: "Implementation of hook_perm()" - the code you're looking at is what was in the original patch. I modified it in the last two patch updates to remove edit permissions because it was behaving unpredictably and I haven't had time to debug it yet (see http://drupal.org/node/48731#comment-85420). I left in the other places in this patch that still refer to that functionality with the hope of enabling "draft editing" like you want. Hopefully I'll have time to work on that in the next few days.

Thanks!

Wow... nice to revisit this thread a few weeks later and find out so much progress has been made. Great work!

chud

Thanx for this update, matt :-)

However, ther's a strange part in your last patch :

-    $form['options']['revision'] = array('#type' => 'checkbox', '#title' => t('Create new revision'), '#default_value' => $node->revision);
+	$form['options']['revision'] = array('#type' => 'checkbox', '#title' => t('Create new revision'), '#default_value' => '');
+	$form['options']['draft'] = array('#type' => 'checkbox', '#title' => t('Save revision as draft'), '#default_value' => '');    
+	/*$form['options']['revision'] = array('#type' => 'checkbox', '#title' => t('Create new revision'), '#default_value' => $node->revision);
+	$form['options']['draft'] = array('#type' => 'checkbox', '#title' => t('Save revision as draft'), '#default_value' => $node->draft);*/

Could you comment about that ?

Hi yched,

Oops. Really didn't mean to leave that part in the patch.

These two lines:

+	$form['options']['revision'] = array('#type' => 'checkbox', '#title' => t('Create new revision'), '#default_value' => '');
+	$form['options']['draft'] = array('#type' => 'checkbox', '#title' => t('Save revision as draft'), '#default_value' => '');    

Just replace the two commented out lines:

+	/*$form['options']['revision'] = array('#type' => 'checkbox', '#title' => t('Create new revision'), '#default_value' => $node->revision);
+	$form['options']['draft'] = array('#type' => 'checkbox', '#title' => t('Save revision as draft'), '#default_value' => $node->draft);*/

Functionally, what this does is to change the system behavior so that when a system administrator edits a node "Create new revision" and "Save revision as draft" are unchecked by default. For all other users, those two items are checked by default (but can be unchecked) when a node is edited. I made that change because I didn't want system administrators (i.e. me) to have to uncheck those boxes every time they made a quick change to a node; but, I did still want those options checked for all other users. The appropriate behavior is debatable - would be negated if Drupal allowed different default node settings based on user role.

Hello mattgrayson,

I will try your latest revised patch. In my situation I find allowing the user to edit their own revisions (ie: make updates to their drafts) seems to work Ok. This is a critical requirement for this drafting patch as without it the draft cannot be worked on during the revision process.

I actually was going to post a comment on the fact that $node->changed is not being updated when the revision is published. The only operation that causes the $node->changed value to update is if the publishing options for create revision are on with out the Create as Draft flag. Otherwise the $node-changed field is remaining as it was.

I think I would like to see the $node->changed field updated to the current system time whenever the user clicks the publish button (from the revisions screen). This would reflect the actual date/time the draft was published.

Thanks.

moving to CVS

Hello mattgrayson,

I applied your latest patch and changed the behaviour as indicated by yched. This has been applied to Drupal 4.7.0 and everything works Ok except can we change one thing. Can you modify the way the Publishing Options work?

What the flags should do is this:

Create new revision should create a new revision.

Save revision as draft should prevent the system from updating the node->nid using node_revision.vid

So, assuming Published is set, then Create new revision creates a new revision and makes it the published document.
Create new revision + Save revision as draft should create a new revision but leave the current document as published.
Save revision as draft on its own would cause the edited revision to be saved but not change the current document to change.

I do not know if 4.7.0 has changed in a way that would prevent this from working, but my previous 4.7.0rc4 installation was working in this way, it is since I installed 4.7.0 that it has changed behaviour. I have looked at the two versions side-by-side but I am unable to understand what is different in them that would cause the change in behaviour.

If you need copies of my node.modules I am happy to provide them.
Thanks.

Hello,

Is there any further work being planned for this patch?

Thanks.

I'm new to the community but I give it my +1. I agree with moshe that there should be a way to provide revisions ahead of the 'published' revision. This would be important for many custom applications that build on top of drupal. I can also think of many instances where this would benefit internationalization - Drupal sites that use the i18n module. E.g. one would edit a page in one language, save it as a draft (unpublished revision), translate to other language(s) and then publish.

In general, I think it's a functionality that is very useful for traditional business-type CMS's.

This issue has been brought up a number of times in the community, in the last two years, e.g.:
http://drupal.org/node/50506
http://drupal.org/node/7582#comment-15693

What is needed for this to be applied to cvs? Drumm's patch at http://drupal.org/node/38451 is also related to this issue.

Killes, what's your opinion on this? Does the patch need any more work after #39 - can it be applied to cvs?

Hello,

If this patch cannot be applied to CVS, can it be made into a module to provide the same functionality? It is really a pain in the arse to have to re-apply this patch every time Drupal is updated (I am currently using 4.7.0 and really need to apply the security patch 4.7.1 or 4.7.2). So far I have applied this patch every release since 4.7.0Beta3 and it has done what I expected very well. The problem is that my sites now rely on this patch and eventually it will be broken when the core changes too significantly for the patch to be applied.

As a proof of concept, the hard work has already been done, the code has been written and I would think enough people have tested and responded to the patch to allow a decision to be made. If a poll is required, then please get on with the job and work out:
a) does the patch negatively impact on the use of Drupal?
b) does the patch positively impact on the use of Drupal?
Given that there has not been too many posts to this subject I would think that people involved are happy with the functionality and now have nothing else to say.

If the answers above are No and Yes, then put it in. If the answer is Yes and Yes, then post what the problems are so they can be addressed. If the answer is Yes and No then I guess I will just have to keep applying the patch until such time as Drupal changes to the point it no longer works.

a) As far as I can tell, just do not tick the "Save Revision as Draft" and Drupal works exactly as it has always done, so no negative impact.
b) The added functionality of letting a community create a draft document, that can be reviewed using the revision system, can be compared using the Diff.module and can be approved by the administrator, rolled back, rolled forward and easily identified as a draft. Yes this adds a very important improvement to Drupal.

So if the issue is the maintainer does not want to add this to core, then please suggest how it can be added as a module (call it drafting.module or something) and let us get on with using Drupal in the easiest maintainable manner that we can.

Thanks.

leaving my mark to look at this on my next batch of free time.

seems noone is working on the patch. Moving to chx land so that it can find its way to core :)

I want to evaluate this.

I also want time.

(for chx, specifically: I also want a pony. :)

[[ subscribing ]]

I'd love to have a 'Save as draft' button next to 'Preview' and 'Submit'! +1 for this feature ...

Subscribing. Can help with testing - is there a "latest and greatest" patch?

Deassigning, alas I do not have the time :(

Is anyone working on this patch to bring it up to speed for HEAD? I think it is a great feature.

Ian

I think the node "moderate" bit was removed in HEAD a few days ago.

I'm not sure whether this direcly affects this patch or not - i'm currently not closely following HEAD dev - but this is kind of related.

In the developement list thread about "moderate bit removal", a "draft feature" investigation was mentioned, but I don't know if there was any follow-up.

We need this patch if we ever want an AJAX "auto-save" feature. Might have time later to work on it.

I realize that you folks are looking for a version of the patch for HEAD, which I don't have. But I do have a patch which fixed some of the issues identified I found with the patch from comment #36, which was only behaving properly for users with "admin nodes" access

Patch is attached.

Any updates with this? Sounds like a great feature for the next release, only a few more weeks left to work on it :-)

as mentioned earlier, the current patch writes to the moderate column of the DB but we recently decided that core was not going to use this column. Perhaps that unneeded code.

it is getting hard to follow this issue and understand whats being done here. i suggest that the next person to touch this code create a new issue and point from here to there. sometimes patches need a fresh life in a new issue.

I was wondering if it was now possible to have that behaviour in drupal. I think it's fundamental to have this for collaborative sites, since the revisions have to be moderated, but the old already published content must not be unpublished while the new revision is accepted???

I'm willing to pay for this feature if anyone is interested in doing it or joining forces to find a programmer that would do it as a module?

Thanks

If this is still active. Can I request that an action_ (maybe called ' save draft as revision') is added to the next iteration.

Thank you.

Hello,

I would just like to say that I am using the modifications to the node.module from this post and it allows me to generate a draft in a usable manner. From a content review perspective all I need is to be able to create a draft document and let people edit it until it is ready for final release. The live document is never altered until the approval is applied at that time the draft document becomes the live document.

This patch works very well as it allows viewing in the Revisions list and allows operations such as Diff. Creating extra fields in tables is not necessary and add complexity.

My vote would be to push for this function to become standard to the node.module or a proper module developed to provide the same feature.

Once this is applied as normal feature, any improvements can be worked on, such as per-user drafting and save-in-progress documents. Especially in the case of save-in-progress documents, this is more than a drafts system as it pertains to an individuals working document, whereas the draft document is generally accessible to many people for comment and review.

Thanks.

Looks like Angela (webchick) is giving this her own shot : http://cvs.drupal.org/viewcvs/drupal/contributions/modules/revision_mode...
(note : this is marked as "not ready yet" :-) )

I'm not sure her module intends to cover all the usages of the "draft feature" that's aimed at in this thread - It seems it will cover mine, though (keep the node published while a "new revision" goes in moderation)

@webchick : if you're following this thread (you probably are, you posted there once) - could you provide some insights about how you envision your module wrt the draft feature discussed here ?

Hi, yched!

I was following this issue for awhile, but it's now completely escaped my grasp and I no longer understand what is being built here. :( So I can't really explain how they compare, sorry. :(

My module was requested by a client, to basically allow the old revision of a node to remain published while a new revision is in moderation. It does this by looking in the DB before the node is submitted, and storing the current published revision in the node table, and then replacing that one in the node table when all's said and done. Then there is an admin panel which will display nodes that have a node_revision.vid > node.vid, and allow the admin to view, approve, and delete revisions using the built-in revision panel.

The "core" functionality works, now it's a matter of solving all the various edge cases; the module is marked buggy and doesn't have a project yet because in during testing, the client managed to make a node completely inaccessible, even to uid 1 which is of course no good. ;) So use it at your own risk, but I would certainly appreciate any help. :)

It's also been brought to my attention that edkwh is working on a module called "draft" that does something similar to this (unfortunately, I didn't know this before I started mine :\). I don't believe his is in contrib yet, but if I see him in IRC later, I'll ask him to post here.

webchick is on the right way. Although the whole issue is great and badly needed functionality, IMHO core shouldn't provide this, like chx already mentioned in #21. It's needed only in certain cases and therefore could happily live in a contrib module (e.g. "drafts module"). Dependencies to moderation modules reinforce this, too. If it's needed for AJAX auto-save, then that feature should be dependent on this module.

As webchick mentioned in #70, yup, I did drafted a draft module after reading this thread. The draft module is similar to what webchick's module does, not setting a revision to the active node. Well, only revisions that are saved as draft that is, and the usual behavior of normal revisions are not affected.

A draft tab would then appear and you can edit drafts and set them to replace the active node accordingly. Drafts are tagged as 'Draft' in the log column of the node_revisions table. It's not the best and cleanest implementation, but it does the job. Using another table would be an option. But yeah, the module is still a draft ;-)

Looking at webchick's module, I think it does a much cleaner job without using extra db space. And like webchick mentioned, I also was not aware that she already implemented a similar module. Now, we are probably look at merging both the module and see what we can come up with :-)

If you want to give the draft module a try, download it from http://drupal47.gempaks.com/files/draft-4.7.zip, http://drupal47.gempaks.com/files/draft-5.0.zip for 4.7 and HEAD respectively. Alternately, you can test it out at http://drupal47.gempaks.com. Haven't apply for cvs access yet..

thanks to you both, webchick and edkwh.
Yes, please, do merge :-)

My personal opinion is that it should go into core, (it seems Dries does as well, btw : see comment #50), but that's probably another debate.

I think this functionality could be made a patch for core once it's working properly.

I'm in the process of reviewing edkwh's module and will post back shortly on the pros/cons of each approaches, and a plan to get it into core.

Ok, edkwh and I spoke on IRC to compare the two. The basic differences are:

1. My module treats all revisions newer than the currently published node as a "draft." edkwh's adds another publishing option ('create revision as draft') to handle that -- so you can have revisions that aren't drafts, although all drafts are revisions.

2. My module re-uses the revisions panel to handle showing "drafts". edkwh's adds a "drafts" tab that shows a list of drafts

3. edkwh's has some permissions defined to add and/or edit own drafts. Mine uses the existing node permissions.

4. Mine simply stores/updates the publishing properties during the nodeapi cycle. edkwh's bases it off a static message in the 'log' column.

Overall, I think edkwh's approach is probably more flexible. One thing I would like to change though is the reliance on the 'log' column and see if the approach revision_moderation uses could be used instead. I'm neutral on the idea of additional permissions, although in core we tend to lean towards fewer permissions rather than more. I'm now going to start debugging some stuff w/ draft.module and see if I can merge the two approaches together.

In the meantime, what do you guys think?

Btw, re: this being a contrib vs. core addition, I am having a really hard time envisioning a use case where it's desirable to have a node that was already approved once made completely inaccessible by virtue of someone editing it. :P So I'm hoping that this could still get into 5.0 as a bug fix if we can pull it off without any API changes.

Hi webchick,

I myself hired another developper to build a module that could allow this functionnality. I don't know at what stage is the project now, but I'll try to get moreinfos and get back to you, so you guys could all get in touch and build the ultimate draft and revisions-while-original-is-still-published module!

Thanks for your work!

Hi, patchak!

Yeah that would be great! :) One great revision handling module is much better than 3 that do almost the same thing. :)

In looking at edkwh's further, I can see why he went the route of a hard-coded "log" column; the node_revision table really doesn't have any other way to insert "meta" data about what a revision actually is. Unfortunately, to add this ability means adding another table, and that will pretty much prevent any chance of this getting accepted into core at this point. So I'm going back to my method of "any revisions that are newer than the currently published revision" == draft.

Yes, 3 attempts (4 including the patch in this thread) - we do need an "official" way to have the functionnality (core or contrib)

@webchick : I get your arguments. I guess this prevents the 'temporary save' features ("I have to walk the dog so I save my unfinished edits so I can come back to them" - and also "auto-save" feature) that some have requested.
That's not what I was after anyway...

yched: not necessarily... I could see another module adding in a "auto-save content to a revision" and then this same system would work. In fact, iirc edkwh is working on that now. :)

I just need to change it so that when a user goes to edit a node, they're either shown their most recent revision, or the currently published revision, whichever is more recent.

("in theory" anyway. ;) I'll let you know how far I get.)

Ok, I made another stab at revision_moderation tonight, probably ready for some testing (not on production sites though :P). Take a look here for changes between it and draft module: http://drupal.org/node/86215

If folks could help test (it's a 4.7 module, but same principles should apply), that'd be great; once it's working, then we can roll those up into a core patch so we don't need the module for 5.0. :D

webchick: tryed revision_moderation and works fine on me (Drupal 4.7.2) once familiarized with the publishing options reverted/not-reverted to defaults on nodes edit >> more at http://drupal.org/node/92263 ).

this is so very useful, thank you! :)

I suggest we close this issue and refer to Webchick's revision_moderation module instead