Simultaneous editing support
Currently there's no good support for two editors editing the same Page (or other Data Object).
We should at least allow locking a page, but better would be adding simultaneous editing a-la Google Docs, etc. If we couldn't get totally simultaneous editing working (TinyMCE might be tricky) we could at least allow simultaneous viewing, with a single person being the current "editor".
SilverStripe have planned this item
This demo might be a good starting point? Uses Mozilla's TogetherJS (WebRTC), so works over browser sockets and doesn't need server side code (https://togetherjs.com/)
It has syncing multiple TinyMCE instances working (you have to click the '+' button at the right side and open the link in a new window to test the demo: http://togetherjs-tinymce.herokuapp.com/
Seems it's included in the project: https://github.com/mozilla/togetherjs/issues/723
Any movement on this? I think that the simultaneous editing would be amazing but could also complicate this too much and slow down the development of a page lock / notification.
Anyway, adding a +1 for this to be implemented in core.
Marcus Nyeholt commented
Some ideas from when this problem came up in the context of Alfresco - a developer built a standalone doc editor to do it, but I think was also looking into an MSWord plugin. The idea was to break the document being edited into separate objects for every 'main' separation break - typically a paragraph - whenever someone started editing somewhere. So to begin with, you have a single document, then as soon as you start editing, that doc is split into the paragraph you're editing, and everything pre- and post- edit point, so you end up with 3 objects; the unedited previous bit, your new paragraph, and the unedited post bit. Of course, if you're editing the first or last paragraph, you may only have 2 new objects. Every new paragraph would create a new object, and every modification to an existing 'unedited' item would split that item into 2 or 3 bits, based on the number of paragraphs present.
Hitting 'save' would attempt to merge your changes back in with a nearby unedited block - or, if no nearby un-edited blocks existed, mark your block as unedited. If all blocks other than yours were marked as unedited, the document could be merged back into a single Content field and stored back against the 'parent' object's content. Merge issues are the responsibility of the last editor to resolve by re-ordering the edited paragraphs into the right order.
The obvious trick to getting it right is how much of the state of things needs to exist serverside, client side, and in-between the two. I'm not masochistic enough to have delved deeply into TinyMCE's API to figure out how it might work, but have a few ideas I want to play around with outside of the scope of the CMS UI to at least see if things are workable without worrying about how it'd be presented to a user to interact with
Michael Andrewartha commented
This comes up time and time in client trainings so it would be good to get it sorted!
Rodney Way commented
This is also this recent'ish module by Shea Dawson - https://github.com/sheadawson/silverstripe-editlock
We've used this a number of times.
Wasn't aware of that module. Will have to take a look to see if there's anything useful. I doubt we'll base new work directly on it though (I haven't had a look at it, but it's 2.4 based so a lot will have broken).
Whether this ends up in core or as a module depends on a lot of things, but mostly (a) how tidy can we make an API so it's not in core, (b) will it require any special server requirements (ReactPHP? Node.js?), (c) how much does the UX need to change to accommodate this feature.
In general I'm in favour of splitting down into smaller modules, but there's a lot of discussion & supporting infrastructure needed before we can do that (what goes into releases? what do we test against? etc).
How does this relate to the concurrent editing module? Would make more sense to bundle this work alongside that module.