Auto-enable "Create new revisions" when "New revisions in moderation" is checked

Here is a possible use-case for having "Create new revisions" set to false while "New revisions in moderation" is checked:

As I was testing my new workflow for a client's site, I noticed that the revisions lists were getting very long and cumbersome as each edit created a new revision. For my purposes all I needed to keep was one pending revision (as well as the current published revision and a history of past edits). There was no need for a new revision on every save, so I turned off the "Created new revisions" default and added the following code to the "submit" case of revision_moderation_nodeapi in revision_moderation.module (line 210 of revision_moderation-4.7.x-1.x-dev line 187 of revision_moderation-5.x-1.x-dev):

        if( $current_vid >= $node->vid ) {
          $node->revision = 1;
        }

The effect of this code is that if "Create new revision" is not checked but "New revisions in moderation" is (or if those are the defaults for the given node type) AND the latest revision is the published one, a new, pending revision is created and saved. Otherwise the module behaves as normal.

The upshot if this is that a pending revision is created if there is none, but if there is one, changes are saved to that revision. This helps reduce unnecessary intermediate revisions.

It seems to work well (on v.4.7 at least, I have not tested v.5) and does not interfere with any existing functionality. It seems like it would be a simple feature add since having the revision moderation flag on and the new revisions flag off currently does not have any logical meaning (and does nothing) but of course it would change behavior in this currently undefined case, so you may want to wrap it in a preference if you like the idea.

Here are some patches in case anybody wants to try this out:

revision_moderation-5.x-1.x-dev (not tested)

@@ -184,6 +184,9 @@ function revision_moderation_nodeapi(&$n
         break;
       case 'submit':
         $current_vid = db_result(db_query('SELECT vid FROM {node} WHERE nid = %d', $node->nid));
+        if( $current_vid >= $node->vid ) {
+          $node->revision = 1;
+        }
         $node->original_node = node_load($node->nid, $current_vid);
         break;
       case 'update':

revision_moderation-4.7.x-1.x-dev (somewhat tested)

@@ -207,6 +207,9 @@ function revision_moderation_nodeapi(&$n
         break;
       case 'submit':
         $current_vid = db_result(db_query('SELECT vid FROM {node} WHERE nid = %d', $node->nid));
+        if( $current_vid >= $node->vid ) {
+          $node->revision = 1;
+        }
         $node->original_node = node_load($node->nid, $current_vid);
         break;
       case 'update':

Sorry for the long post, I just figures somebody else might find this functionality handy.

Ronan
Gorton Studios - http://www.gortonstudios.com/

Very interesting.

This would become close to perfect if it was combined with a setting that specifies how many revisions to keep for each new "revision cycle".

For example, if the settings is set to save 3 (in total), and there are already two revisions in the current cycle that has not resulted in a new publish, then the oldest is disregarded (deleted), the current revision gets replaced by the current save, and is then (after the current save) revision 2.

Hence, during the save, the following has occurred:

Before the edit, the node is for example "Published-version 1".
During its revisioni cycle, lets say it has kept the 3 last revisions (say rev.1a, rev. 1b, and rev.1c) that led to that publish, so 3 revisions exist in its revision history.

When editing the published node and saving it ONCE, the result is as follows:

The published node is untouched.
A new "branch" is created, using one higher number: 2:
Consequence: Rev. 2a is created (it is a revision, as it is not published yet)
And the revision table now looks like this, newest on top:

Rev. 2a. (the save that was just done as a new revision of the published node).
Rev. 1c. (latest one of the existing revisions that led to the currently published node)
Rev. 1b.
Rev. 1a.
And the published node, of course, which in practise is 1d, but actually published/approved. (To avoid confusion, I dont refer to the published versions as revisions here).

Then, the next save, still before the 2a has been published, is giving us 2b, and the history looks like this:

Rev. 2b. (the current/latest save)
Rev. 2a.
Rev. 1c.
Rev. 1b.
Rev. 1a.
And the published node, that is still in practise 1d.

Then, after 2 more unpublished saves, the list looks like:
Rev. 2d.
Rev. 2c.
Rev. 2b.
(Rev. 2a has now been deleted, as only 3 revisions per publish cycle is kept, pretending that such a feature exist, which is what I am trying to make a practical use case of right now...)
Rev. 1c.
Rev. 1b.
Rev. 1a.
And the published node, that is still in practise 1d.

Then, finally, when NOT making a new revision (no 2e), but approving/publishing 2d, the result looks like this:

The published node is replaced by 2d.
(Rev. 2d is not in the revision list anymore, as it is the published version now.)
Rev. 2c.
Rev. 2b.
Rev. 1d. (the previously published version, now replaced by 2d)
Rev. 1c.
Rev. 1b.
(and Rev. 1a is deleted, keeping only 3 revisions from cycle 1)

Next revision after this published version, will then be 3a.
Lets say Rev. 3a is approved almost instantly, without further revisions.

Then the list will look like this.

The published node is replaced by 3a.
(Rev. 3a is not in the revision list anymore, as it is the published version now.)
Rev. 2d. (the previously published node, now pushed into the revisioni history)
Rev. 2c.
Rev. 2b.
The rest - the old cycle(s) - remains untouched:
Rev. 1d. (the previously published version, now replaced by 2d)
Rev. 1c.
Rev. 1b.

There could be a second setting, stating how many cycles to keep - for example 3 there too, then there will at all times be maximum 9 revisions and 1 published node.

However, if so, I would think it was a good thing to be able to mark certain revisions as "reference revisions", to keep them from being deleted indefinetely.

Could also be that we could have a possibility to set that all revisions that has inideed been published is to be kept anyway, so that the number of revisionis to keep does not affect the published versions.

Ooops, I copied/pasted a list and forgot to delete a parenthesis in the last list example:

This one:
"The rest - the old cycle(s) - remains untouched:
Rev. 1d. (the previously published version, now replaced by 2d)
Rev. 1c.
Rev. 1b."

Should be simply:
(the parenthesis after 1d is removed, as it is only relevant to the previous list)

"The rest - the old cycle(s) - remains untouched:
Rev. 1d.
Rev. 1c.
Rev. 1b."