Currently, Diff is using node_revision_list() or diff_node_revision_list() which order the revisions by 'vid' and on the Revisions tab, it enforces that the lower 'vid' is always on the left, and the higher 'vid' is always on the right.

Unfortunately, Drafty (used by Workbench Moderation and others) makes a wacky revision spaghetti, where the highest vid always belongs to the published revision. This means that drafts modifying the published version have lower vids, and so comparisons against the published version are always backwards: from a newer draft on the left, to the older published version on the right!

Ordering the revisions by the timestamp (along with some Drafty and Workbench Moderation patches to correct the timestamp!) will bring sanity back to revision comparisons with Diff :-)

Since there isn't normally a way to override the 'timestamp' (node_save() always sets it to the request time) ordering by 'timestamp' should be effectively the same as ordering by 'vid' -- only in the case where two revisions have the exact same 'timestamp' could there be differences (and we can do ORDER BY timestamp DESC, vid DESC to prevent that problem) so this should be safe to do even on sites that aren't using Drafty or Workbench Moderation.

For reference, here's the Drafty and Workbench Moderation issues that will correct the timestamp to reflect the real history:

At least the Drafty one seems to have some momentum, and I suspect it'll get merged eventually. The Workbench Moderation one is new yet.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dsnopek created an issue. See original summary.

dsnopek’s picture

Issue summary: View changes
dsnopek’s picture

Status: Active » Needs review
FileSize
4.42 KB

Here's a patch to implement this enough that revisions can be compared in the correct left/right order. It doesn't fix the "Previous different" / "Next difference" links, but there's a whole separate issue for making those work with Workbench Moderation already:

#1833950: Better Workbench Moderation integration

Unfortunately, workbench_moderation copy-pasted the logic in diff_node_revisions_submit(), which force the revisions to be compared in vid order, so another workbench_moderation patch will be necessary for this to actually work. Jeez! Soooo, many patches. I'll post a link to that patch in a bit.

dsnopek’s picture

FileSize
4.72 KB
422 bytes

Fix a stupid bug :-)

dsnopek’s picture

jollysolutions’s picture

Status: Needs review » Reviewed & tested by the community
broon’s picture

Status: Reviewed & tested by the community » Needs work

So, I applied all three patches successfully, that is

Unfortunately, the revisions on the Compare page are still in same order as before: published version (highest vid) on top, current version (second highest vid) just below. Am I missing something? How can I help debug, namely where should I start looking?

dsnopek’s picture

I think it will only affect new revisions that are created after applying these two patches:

  1. #2579205: Delete redundant revisions
  2. #2824798: Forward revisions break publishing audit trail

Without those, the timestamps don't get corrected and so timestamp order and vid are the same.

Sorry for the massive patch soup! There's a lot of little things in a lot of places that need to be adjusted to address this. :-/

jollysolutions’s picture

Status: Needs work » Reviewed & tested by the community
mrgoodfellow’s picture

After applying this patch I am still not getting the correctly expected result when comparing revisions.

After patching, when selecting the top two revisions to compare (RID 2001 = Published, RID 2000 = Previous/Drafted)

When comparing the published node content is appearing to the left with the previous data appearing to the right.

'published revisions (RID= 2001)' -> 'previous revision (RID= 2002)'

It looks like its still trying to calculate the highest revision ID to display to the right rather than the newest timestamp.

If I THEN click 'Previous Revision' I am now taken to a page where the revisions display as they should.

mrgoodfellow’s picture

So I've done some further investigation. So far here is what I have found:

function diff_node_revisions_submit() is the action that submits the form. It has some logic that sets the $old_vid and $new_vid based on time-stamp.

However, it appears this redirect is not triggering properly as when I initiate it, the $form_state['redirect'] value will return as intended in the logs, but the actual redirect continues to be structured as:
/node/7702/moderation/diff/view/$new_vid/$old_vid

This is wrong as its comparing New to Old instead of Old to New.
I'm continuing to investigate.

mrgoodfellow’s picture

I was able to resolve the issue with Workbench Moderation revisions and Diff comparisons.
First I applied this patch and the workbench moderation patch found here:
https://www.drupal.org/project/workbench_moderation/issues/2824798#comme...

After applying the patch, when comparing revisions, the comparison was comparing NEW to OLD instead of the expected OLD to NEW

the issue appears to be related to the following workbench moderation function:
function workbench_moderation_diff_node_revisions_submit($form, &$form_state) {

I was able to re-write this function as follows: (based off this diff patch)

function workbench_moderation_diff_node_revisions_submit($form, &$form_state) {

  // the ids are ordered so the old revision is always on the left
  $revisions = $form_state['revisions'];
  if ($revisions[$form_state['values']['old']]->timestamp > $revisions[$form_state['values']['new']]->timestamp) {
    $old_vid = $form_state['values']['new'];
    $new_vid = $form_state['values']['old'];
  }
  else {
    $old_vid = $form_state['values']['old'];
    $new_vid = $form_state['values']['new'];
  }
  $form_state['redirect'] =  'node/'. $form_state['values']['nid'] .'/moderation/diff/view/'. $old_vid .'/'. $new_vid;
}
mrgoodfellow’s picture

I found another issue in this patch. When you hit the revision limit on a page, there is a function in diff.pages.inc that splits the revision list based on the 'REVISION_LIST_SIZE' parameter (set in diff.module line 11)
When the revision list gets split, the revision object identifier remains in a 0-49 sequential order. The action in 'diff_node_revision_list()' adds the vid as the revision identifier but the pager action removes this association.

My solution:
Update diff.pages.inc
Line 56 (add)

foreach ($revisions as $revision) {
$revisions[$revision->vid] = $revision;
}
This goes back to the chunk and adds the associated vid so that the previous 'workbench_moderation_diff_node_revisions_submit()' updates will correctly order the revisions by timestamp.

I'll get a patch out for this shortly.

See also: https://www.drupal.org/project/workbench_moderation/issues/2824798#comme...

mrgoodfellow’s picture

I apologize as my ability to create patches has been limited. I am currently waiting for the drupal changes to migrate to GitLab so I can create patches easier. If anyone would like to create a patch with my suggested update to Line 56 of diff.pages.inc that could help push this issue forward. As it is, I am not able to deploy this module without the patches. (or things break)

mrgoodfellow’s picture

Ok, I was able to get git working again and roll a patch with my update. Again, I apologize for the delay. This patch is to allow diff to work with Workbench Moderation and correct the issues with forward revision and revision order when comparing revisions. My additional update fixes the issue when revision history is paginated.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 15: diff-sort-revision-timestamp-2881771-15.patch, failed testing. View results

Alan D.’s picture

+	foreach ($revisions as $revision) {
+      $revisions[$revision->vid] = $revision;
+    }

There is a tab instead of two spaces before the foreach().

Personally haven't tested this, but there is a slight risk $revision->vid will match an array index in $revisions. Better to assign these to a fresh array.

dsnopek’s picture

Status: Needs work » Needs review
FileSize
5.32 KB
730 bytes

Here's a new version of @mrgoodfellow's patch from #15, but fixing the review from @Alan D. in #17. I've also included an interdiff between #4 and this patch, so that it's clear what @mrgoodfellow was adding!