I just committed a change that stops the 1.x branch from colliding with diff module and does very basic UI integration. It could be a lot better and should be rethought in 2.x

Comments

stevector’s picture

jenlampton’s picture

I'm down to help with a new UI when the time comes :)

jwilson3’s picture

For reference, and to get the UI ball rolling... there was an initial visual idea for 1.x on #1083720-31: Incorporate Diff to Compare Revisions for incorporating diffs right into the revision moderation page itself. Just want to make sure that doesn't get lost. However, regarding that mockup, I'm not too keen on introducing a drop-down box for selecting the diff. That proposal also limits you to doing a diff between only the most recent revision and one other... with no wiggle room for comparing random revisions from random dates.

Meanwhile, the radio-button based UI from the Diff module is very easy to use and understand, so my proposal would be to simply integrate that functionality directly into the revision moderation page's table.

Unfortunately, the 7.x-2.x code was giving errors, so I pulled the following mockup together based on the 1.x version -- hopefully its not too far off...

workbench moderation compare revisions

hass’s picture

That's very cool. I like this mockup a lot more than the current tab, but until it's committed we should change the strings. Your Compare is much better here, but this highly depends on the context :-). In the menu link I think the Differences is better... the Show differences button maybe better named Compare.

Are you working on the above implementation?

jwilson3’s picture

I havent started working on it yet... I looked a little bit at the diff code, and the code for building the revisions table. As I see it, since you cant have two forms inside one another, the entire table need to be wrapped in a form, and there will be two different possible operations 1) the pre-existing state-change of the current revision with the "apply" button 2) the old/new comparison radio buttons with the "compare" button. Thoughts?

Side note, I did mention "Compare" on a ticket for the Diff module #1785742-2: Diff module string review, which assuming hass's patch in #3 there lands in the Diff module at some point, and assuming we implemented this with the text "Compare" -- that would be keen.

Second side note: I actually modified the existing tab's name in the 7.x-1.x code on a client's install from "Diff" to "Compare Revisions" (more user friendly).

hass’s picture

We always write the first word ucfirst and rest lowercase. This means Compare revisions. We can change the patch in #1780480: Change 'Diff' to 'Compare revisions' in tabs for easier translation to follow your wording. Sounds really better. I will try to create a new patch asap.

hass’s picture

Depending on buttons you can fire different functions as I know (submit functions). Cannot remember that I have ever done it myself in one form, but you can catch the submit in workbench module and call a diff function and sending all the params over to the diff module function. This should work.

Here is just one example how I've done this in linkchecker. This way you may add a custom submit handler to every individual button. Could be just a few lines of code...

/**
 * Implements hook_form_alter().
 */
function linkchecker_form_alter(&$form, &$form_state, $form_id) {
  switch ($form_id) {
    // Catch the custom block add/configure form and add custom submit handler.
    case 'block_add_block_form':
      // Add custom submit handler to custom block add form.
      $form['#submit'][] = 'linkchecker_block_custom_add_form_submit';
      break;
alan d.’s picture

Cross posting #1833950: Better Workbench Moderation integration.

This should ensure that you keep the correct context within the Workflow Moderation module when using the Diff module. Awaiting reviews from others (with and without Workflow Moderation enabled) before pushing out.

Note only ~1 or 2 days before releasing the first official release of the Diff 7.x-3.x branch, so quick feedback from others is required to fit this in.

To update the admin path, Diff 3.x uses

/**
 * Implements hook_admin_paths_alter().
 */
function diff_admin_paths_alter(&$paths) {
  // By default, treat all diff pages as administrative.
  if (variable_get('diff_admin_path_node', 1)) {
    $paths['node/*/revisions/view/*/*'] = TRUE;
  }
}

Side-note: Which maybe should be defaulted to variable_get('node_admin_theme').

variable_get('diff_admin_path_node', variable_get('node_admin_theme'))

Also related, the direction that Drupal 8.x is taking with the UI #1776796: Provide a better UX for creating, editing & managing draft revisions.