Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
We have the basic UI functionality for conflict resolution, but we need per field conflict resolution. Ideas are welcome!
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | conflict-visual-diff.png | 231.5 KB | hugovk |
| #8 | Conflict inline resolution.png | 51.18 KB | hchonov |
| #8 | Conflicts notification dialog.png | 202.24 KB | hchonov |
Issue fork conflict-2910910
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
bircherFor text fields (ie the body filed) I would 3-way-merge the text with https://github.com/bircher/php-merge.
If there is no conflict, the merged text is good to go.
If there is a conflict, I would resolve it once with "mine" and once with "theirs" and pass those two texts to http://xiphe.github.io/jQuery-Merge-for-php-diff/ and let the user resolve the conflicts by selecting the version that should be accepted.
Comment #3
hchonov@bircher, thanks for pointing out those tools.
if the php-merge library successfully merges the two versions without conflicts, I think that we still need to inform the user about the newly created text. Think about a text representing some medical diagnosis - the first user changes or adds more details in the text, based on which the following decision is taken and the second users not yet aware of those changes by the first user adds another sentence which is not conform with the additions made by the first user.
Do you want to show pure html to the user?
Comment #4
timmillwoodWe also worked on a merge library a couple of years ago: https://github.com/relaxedws/merge
Comment #5
bircherYes of course we should always show the text that is merged. But I think it is ok to then let an editor create a new revision on top of the merge "commit".
I think we probably have to be flexible with it. For the use case I had in mind the text is in a special flavour of markdown, so the text representation is enough to decide on how to solve the conflict. But with html it may be better to show both merged texts (so resolving the conflict with either of the revisions) and then let the user decide which to use and fix things up in a follow-up edit.
Yes I checked out the relaxedws merge library too and we might need both in fact. the relaxedws merger is optimised for arrays so entities with their fields and it is great at merging an edit to the tiltle on one revisiom snd an edit to the body on ghe other. The bircher/php-merge is for text-merge and tries to behave the same way git does. I compared the two (two years ago) and the tests on one fail the other and vice-versa so they really try to do something different. see https://github.com/bircher/relaxed-merge-wrapper/
Comment #6
hchonovThe 8.x-2.x-dev branch of the module already is performing the automatic merges, so it stops only where conflicts are detected. How should those merge tools help us when we have a merge conflict on a field? I I was thinking about showing the form element for each version in a pop-up, something like PHPStorm and let the user decide how to merge - on the left side there is your version, on the right the server version and in the middle the result of the mix.
Comment #8
hchonovIn order to have some UI resolution at all, I've implemented an overview of the three field versions. This is definitely not the final UI, but just a starting point and for demonstration purposes.
Comment #9
hugovk commentedHello!
Here's our proposal.
For fields with conflicts, we're using the
Drupal\Component\Diff\Diffmodule to make one diff of initial vs. local versions, and another of the server vs. local versions.We also add a
#descriptionhelp text.Patch to follow.
Comment #10
hugovk commentedComment #12
mlncn commentedThis would be amazing. hugovk's mockups look great.
(There's no code in the merge request, correct? I'm never 100% sure here.)