Allow direct publishing of revisions rather than copying

I have to correct something from the issue description. The little problem I was talking about, is in fact not a problem. It is working well! So thats ok.

Still, I would like to hear some reactions on the idea of just changing the revision status instead of copying the revision.

Since I have a positive reaction, here is an attempt.
Apply the patch, go to yoursite.com/admin/settings/revision_moderation in order to set the default behaviour and you are ready to give it a try.

If you choose 'promote' instead of 'copy', it will simply promote the status of the node to the current one and add some log information on when the revision has been promoted. Perhaps we might also add some extra information who promoted it etc...

In case you can't apply a patch, find the full module attached (be sure you change the name if it is different than revision_moderation.module)

There were some issues with the previous path so here is a new one.

Thx webchick. It really needs some more testing. I found another mistake. A new patch is provided.

There is one more thing I don't have a clear solution for. Before describing the issue, I'd like to state some definitions:

1. revert a revision = copy the selected revision to a new one and publish the new one as the 'current revision' (default behaviour)
2. promote a revision = publish it as the 'current revision' without creating a copy revision first (new optional behaviour)

Description of current workflow:
When the revision list is being displayed, the actions next to the moderated revisions are: revert and delete. If you would like to promote a revision, you need to view the revision first and then click the publish revision link. Of course, this will only work after applying the patch and set the right behaviour in admin/settings/revision_moderation.

Problem:
There is no way to promote a revision from the revision list. You see only the revert and delete possibility, no promote possibility.

Solution:
We should be able to alter the revision list by

• or replacing the revert action by the promote action
• or add an extra action like promote next to the revert action

Implementation:
Altering the revision list is not possible with the core function node_revision_overview. But the new diff module, gives us the opportunity to alter the 'diff_node_revisions' form (see diff_diffs_overview function).

Conclusion:
The best solution would be changing the core node_revision_overview function so the core form can be altered by the diff module and the revision_moderation module. The change can be as simple as: replace the code from the core node_revision_overview function with the code from the diff_node_revisions function in diff module.

Is there someone who feels something for doing this? It's clear that the diff module has better code than the code fom the core and it this module can benefit from it!

I opened an issue http://drupal.org/node/116798 for changing the core code so it can help the revision_moderation module for future enhancements.

Perhaps there is another solution: override the 'node/$nid/revisions/$vid/revert' path by another module.

Anyhow, I am starting to understand we should not change the current revision_moderation module. It's better for now to add an extra module which extends this one. We'll see in the future whether it can be incorporated.

This will probably be the last follow I post. The made a solution for this issue using the new diff module. So, it wont work without this module.

Because the diff module overrides the revisions list and implements a form, I am able to alter it via a new module. Here is the code within that new module:

In the menu hook:

  if (arg(0) == 'node' && is_numeric(arg(1))) {
    $node = node_load(arg(1));

    // Callback to allow users to edit revisions.
    $access = user_access('administer nodes') || (user_access('view revisions') && node_access('update', $node));
    $items[] = array(
      'path' => 'node/'. arg(1) .'/revisions/'. arg(3) .'/publish',
      'title' => t('promote revision'),
      'callback' => 'revision_moderation_publish',
      'callback arguments' => array(arg(1), arg(3)),
      'access' => $access,
      'type' => MENU_CALLBACK,
    );
  }
  return $items;

In the form_£alter hook:

  // In order to apply this alter, the diff module mussed by enabled
  if ($form_id == 'diff_node_revisions') {
    $node = node_load($form['nid']['#value']);
    
    $revert_permission = FALSE;
    if ((user_access('revert revisions') || user_access('administer nodes')) && node_access('update', $node)) {
      $revert_permission = TRUE;
    }
    
    foreach ($form['operations'] as $vid => $operations) {
      if ($revert_permission && $vid > $node->vid) {
        $form['operations'][$vid][0] = array('#value' => l(t('publish'), 'node/'. $node->nid .'/revisions/'. $vid .'/publish'));
      }
    }
  }

In this form alter, all the revisions under moderation (= with a vid > vid of the current reversion) will get a 'publish' action instead of a 'revert' action.

And we end with adding a new function in order to avoid the copy from the revert action.

function revision_moderation_publish($nid, $vid) {
  global $user;
  $log = t('Revision approved by %name on %date.', 
           array(
             '%date' => theme('placeholder', format_date(time())),
             '%name' => l($user->name, '/user/'. $user->uid)
            )
          );

  // The node_save($node) function does not suit for this action because it overwrites the revisor name by the one that is promoting this revision
  // Update node and revision table
  db_query("UPDATE {node} SET vid = %d WHERE nid = %d", $vid, $nid);
  db_query("UPDATE {node_revisions} SET log = '%s' WHERE vid = %d", $log, $vid);
  
  drupal_set_message(t('%title has been published as the current revision', array('%title' => theme('placeholder', check_plain($node->title)))));
  $node = node_load($nid, $vid);
  watchdog('content', t('%type: published %title revision %revision.', array('%type' => theme('placeholder', t($node->type)), '%title' => theme('placeholder', $node->title), '%revision' => theme('placeholder', $revision))));
  drupal_goto('node/'. $nid .'/revisions');  
}

That's all.

Knowing that Moshe is maintaining the diff module (together with rötzi), I think he might be able to present the code of the overridden revision path to the core. Of course, this doesn't mean that it will be committed for 4.7.x or even for 5.x. So, I'm a bit pessimistic.

For now, I will handle my workflow with #10 solution. I have to concentrate now on other things. Perhaps marcob can take over some of my tests and find another way.

So, I might come back in a few weeks on this. We'll see. Thx for looking into it and for the feedback.

Just check the patches or work arounds in the previous follow ups. They will give you indication how the revision system works and how you can get around this issue in several ways.

You're making me very curious now ...

Oops, my follow up was posted 'en retard'.

Just a quick question: what if you are on an older revision (not one under moderation but one older than the current revision) and you would like to publish that one. Once you did, the younger revisions will appear under moderation. That's behaviour you don't want.

So, in case of an older revision (older than the current), you still want the revert action. This is equal to: all the revisions under moderation (= with a vid > vid of the current reversion) will get a 'publish' action instead of a 'revert' action, the rest stays with the 'revert' action.

Does this make sence?

One more problem: the node title is not updated!

I also added some watchdog info, so you can track who published a revision under moderation.

The previous patch did not follow the correct watchdog syntax. My mistake: I didn't look at the watchdog function in the api.
Fixed now.

It's up to us to work towards a nice solution and present it to the core devs. Perhaps we can meet eachother on OSCMS (22-23/03) and work it out (creating patches) together with rötzi and moshe. Nevertheless, I don't have an opinion whether this revision_moderation/diff mofule should be in core or not. It can perfectly live as a contrib module as long as the core leaves some doors open to extend the current functionality.

Other than that, I'm pretty happy with the solutions we came up with so far.

Indeed. My solution is to use the dif module and then do a form alter to change the revert action into publish action.
Here is my 4.7 solution which I'm going to test now for 5.1

function hook_form_alter($form_id, &$form) {
 
  // In order to apply this alter, the diff module must by enabled
  if ($form_id == 'diff_node_revisions') {
    $node = node_load($form['nid']['#value']);
    
    $revert_permission = FALSE;
    if ((user_access('revert revisions') || user_access('administer nodes')) && node_access('update', $node)) {
      $revert_permission = TRUE;
    }
    
    foreach ($form['operations'] as $vid => $operations) {
      if ($revert_permission && $vid > $node->vid) {
        $form['operations'][$vid][0] = array('#value' => l(t('publish'), 'node/'. $node->nid .'/revisions/'. $vid .'/publish'));
      }
    }
  }
}