When two people edit wiki posts at once, someone always overrides another person’s post. How hard would it be to have a google docs-style of editing, where it doesn’t override? Alternatively, a functional merge would be nice, while a lock, even though it is better than nothing, is not the best option (as is discussed in Edit lock when editing posts; especially wiki post).
One thing we could do through the message bus is alert people when they begin editing and someone else is already editing. On wiki posts I mean, moderator collisions on edits have to be absurdly rare.
I resisted this for Stack Exchange, instead we did a “whoever made the longer set of edits wins” hack, but we have the systems in place to do real time notifications in Discourse.
12 Likes
We’ve been running into this quite a bit with one of our more frequently edited wiki posts. Keep in mind wiki posts are by TL, so it isn’t directly for moderators (ours happens to be “spf staff”, as we have it in a private category, but we still get several of them wondering why their changes suddenly disappeared.
1 Like
FWIW, this issue, along with restricting edit permissions, is preventing adoption of wiki posts on my system. I’ll grant that as a small, private community we may be an edge case.
How does Wikipedia manage this? (Or other such popular systems?)
1 Like
If you care to do some research on that and share your findings that’d be appreciated 
2 Likes
WIkipedia’s edit conflict workflow is outlined here:
My takeaways:
Wikipedia doesn’t indicate when multiple people are editing the same page, as Jeff suggested above. I think is a good idea in Discourse’s case. I’ve seen this model used in MailChimp and other places.
On Wikipedia, after someone tries to save a page, they get an an “edit conflict” page, which gives the user a chance to reconcile the differences manually:
This seems like an intimidating screen, but I think most of the pieces are there already for Discourse, if it seems like a good idea to implement.
A possible spec would be (in order of importance):
- Indicate when another user is editing the same post.
- Indicate, when saving, that the edit would overwrite someone else’s work – allowing the user to continue or stop.
- As above, but also providing a diff between the user’s version and the current version
- As above, but with the addition of a text editor to allow the user to merge changes manually
1 & 2 seem reasonably easy to implement and would be helpful even without 3 & 4. I’m not sure how the UI would work for 3 & 4.
12 Likes
This might be a natural addition to this plugin: https://meta.discourse.org/t/discourse-who-is-writing-a-reply/48420
Seems like that plugin is in need of an update anyhow, and @adrapereira hasn’t been around for a while. We can sponsor this work if anyone’s interested.
5 Likes
I might be interested in this once my GSOC project is over in a couple of weeks - the ‘presence’ features are somewhat related to my whos-online plugin. 
8 Likes
One other thing that Mediawiki (the Wikipeda software) does is help prevent conflicts by letting people just edit sections.
Two people can edit two different sections (eg H1/H2 delimited blocks) at the same time and not see the conflict resolution page afterwards. The talk pages also have an “add new section” feature, which lets a new section be added with no risk of edit conflict.
8 Likes
https://meta.discourse.org/t/discourse-presence-who-is-writing-a-reply/48420?u=erlend_sh now supports “who is editing”.
https://meta.discourse.org/t/discourse-presence-who-is-writing-a-reply/48420/26?u=erlend_sh
10 Likes
I am reopening this cause the underlying problem still exists, even with presence. Sure we show that two people are editing. But only one person wins now and another loses.
We can sort this out very cleanly if our edit API always includes “this is the revision I expect to be it” with the payload and raises if the revision does not match.
So the process would be:
User A: starts editing (revision is 1)
User B: starts editing (revision is 1)
User A: hits save (current revision is 1) -> 200
User B: hits save (current revision is 1) -> 409
User B: presented with “It looks like the post was updated since you started editing, save anyway? (Yes, No)”
In theory we could do automatic conflict resolution as well which could make the wiki use cases a bit stronger. (calculate diff based off revision, and attempt to apply it to latest)
I do not want to gold plate the feature for the next release with full on conflict resolution windows proposed bye @alehandrof, that can come later. But at least saying “on no, you are going to nuke someone’s edit” would be nice.
Overall, the issue is a lot more of an issue if the community have lots of wiki topics.
14 Likes
That would be awesome, thanks so much!
Just stating the obvious here: one thing that kinda helps is to spread larger wiki post into several smaller ones and perhaps linking them together in the OP.
2 Likes
This might be a silly idea, but what about pre-empting a revision number whenever the editor is fired, so that both revisions can be saved, and then after the conflict resolution can happen? If there’s no save, the revision can be dropped as a no-op.
1 Like
I worry cause effectively edits still get nuked for somebody and on large wikis it is very unlikely you would notice it till too late.
1 Like
@nbianca added a safeguard 
https://github.com/discourse/discourse/commit/f60b10d090171c49134b20abcfb089ebb94fad21
7 Likes
@nbianca can you add a cropped screenshot of this in action? That’d be 
3 Likes
Sure! 728 screenshots below 
9 Likes
I see, I was hoping for a are you sure kind of prompt here vs this flow
7 Likes