Highlight modified and conflicting fields during conflict resolution

The problem with form_set_error() is the form doesn't get rebuilt if there are errors. I think doing some of the stuff that #ajax does regarding messing with the cached form might work as a workaround though.

> highlight the affected fields when reporting about modifications or conflicts.
What about saving another revision and redirecting to a Diff view? Also, Revisioning is able to support nodes (not entities) in multiple states.

There was also this early stage Conflict Resolver module that might help a tiny bit.

Per https://association.drupal.org/node/18268, a dev is needed here. I'll run with this.

Conflict Resolver is D6 only, it likely won't help.

I don't really want to install Revisioning just for this.

Saving another revision and using Diff sounds complicated.

I think we should keep this simple and within Conflict module. If there is a way to use the existing Form API error styles during build, that should be okay.

So another project landed on my plate and I'm not going to be able to get to this for a while. If somebody else wants to pick it up and run with it, go for it. Otherwise, I'll circle back and take a look in a week or two.

Moving out of the launch priorities since this feature can be deployed whenever it is committed to conflict module.

(tag)

Here is patch, pure form_set_error() does the jobs.

This completely prevents the form from being saved. The "Save again to overwrite it." part of the error message should work as it says. See also comment #1.

Can we set the error class or otherwise mark it in the $form array?

Yes, my bad. Here is patch with pure highlighting through 'error' class

      // Will add error highlighting for text fields
      $form[$field_name][$langcode][0]['#attributes']['class'][] = 'error';
      // Will add error highlighting for list fields: radios, checkboxes, multiple term reference, etc
      $form[$field_name][$langcode]['#attributes']['class'][] = 'error';

Do we really want to always set both? Actually, this might want to iterate over all the children, for multiple-item fields.

Thinking out loud:

function _conflict_apply_error(&$elements) {
 // Recurse through all children.
  foreach (element_children($elements) as $key) {
    if (isset($elements[$key]) && $elements[$key]) {
      _conflict_apply_error($elements[$key]);
    }
  }
  // If there are properties, it's probably safe to set #attributes here.
  if (!empty(element_properties($elements)) {
    $elements['#attributes']['class'][] = 'error';
  }
}

Appears to work so far!

Added some doc corrections and marked RTBC because they are so minor.

Let's add unit and/or integration tests here.

This module continues to cause lots of pain for d.o. Root cause is a total lack of tests.

m1r1k, please, re-assign to yourself if you are planning to work on this.

Here is fixed version with tests.

Why was this change made?

         // Checksum the data so it's directly comparable.
-        $sum[$k] = md5(serialize($f[$k]));
+        $sum[$k] = $f[$k];

Attached is an untested re-roll.

(This will likely need another re-roll, #2210937: Conflict module over-reporting conflicts during crosspost, preventing issue updates incorrectly covers some of the same changes in a different way, that looks more thorough.)

Another untested re-roll.

Improved re-roll, I missed some now-redundant code.

It looks like the messages are correct with manual testing. They may be swapped around in the test.

This patch replaces

    // Force reload the node.
    node_load($conflict->nid, NULL, TRUE);

in testComplexTroublesCase(), to be sure it isn't a cache problem.

This corrects the Title field label in _conflict_get_node_changes(). "Node" should not appear in UI text, and the tests test for that.

I think the new diff algorithm was detecting the difference between NULL and an empty string in the Body's summary. The UI will never generate a NULL summary, so this sets it to an empty string in drupalCreateNode().

That's better. Thanks for the thorough tests!

Now deployed on Drupal.org.