Discourse Shared Edits

I think I noticed a bug today. If you enable shared edits in the first post of the topic, the topic title is empty in the composer. When I save it, the title is retained. The screenshot below is from Teams, but I also am able to replicate on a normal Discourse site with shared edits plugin enabled.

Screen Shot 2021-04-24 at 2.13.57 PM


As I am testing the plugin for my workflow for holding webinars on discourse, I made a video of how it behaves so it can serve you all:


We just did a small-scale test with 10 concurrent users, and most of the time it just reads

after hitting the EDIT button. Any ideas how to debug this?

1 Like

Have a look at logs, is there anything there?

1 Like

Several of them:

1 Like

How long was this document you tested on? If you test again on a shorter document don’t see it work?

1 Like

It was just 10 lines long:

1 Like

Any consistent repro? 2 people editing? 3,4?

1 Like

6 people were editing at the same time. 4 other people didn’t “get in” but got the “Internal server error” message. If any of the 6 people left the editing via “Done”, they werent able to re-enter the editing, too.

Those 10 were the only ones loged into discourse at the time, so no stress on the server (we are still in testflight mode for our social intranet, looging great so far).

1 Like

And another observation: the topic seems “broken” now - I can’t enter via “edit” but just get the server error, while no one else is editing any more.

I did a wiki-rewind to a version long ago - still no cigar, just the server error.

1 Like

A consistent repro will help lots, can you make this happen again on a new post?

1 Like

We just startet another topic and added 1 person at a time - that worked.

A few other observations:

  • cursors/colors would be super helpful (I read the comments above but just my +1 for this feature)
  • it would be helpful to see who else is in editing mode. So not just when actually writing, but in editing in general. A UX solution would be to always show the avatars and just ad a :fountain_pen: symbol if they are actually writing. If there are too many: show a text “x users are in edit view”.
    Right now I am missing a sense of “am I alone or are there others around”.
  • If I enter the max-view, the “editing…” displays are invisible alltogether. They come back if I shrink the window again.

We would love to use Shared Edits to collaboratively edit meeting notes in real-time, but a few things have made it challenging (echoing some of the other comments in here):

  • Long delay before you can see what others are typing
  • No cursors to show where others are
  • Hard to know when you might be stepping on others toes

One thing I wanted to recommend looking into is HackMD’s implementation of collaborative markdown editing. I think they’ve done an awesome job in making all of the above possible. It would be awesome to see Discourse’s shared edits capability at par with theirs.

Perhaps something to look into with their realtime engine here:


Amen. HackMD (or HedgeDoc, a spinoff) is what I would label “best of breed” in this regard.


Sadly using AGPL is completely off the table for us, so all we could do is borrow ideas (from hackmd, google docs and so on)

I agree multiple cursors will help a lot, I certainly want to get to it, sadly it is fairly tricky cause we would need the plugin to swap a TEXTAREA with a contenteditable section. No specific roadmap on when we will get to it, but I am considering just sponsoring some work here and contracting out some of these experiments. The engine itself knows where the cursors are.

This sounds a bit odd, there are certainly delays rendering it on the topic page, but the composer itself should be 100% live and pretty much instant. This could be related to how you have Discourse hosted.


We did some further testings on odd behaviours of the - otherwise great - shared edit mode. Here are some findings:


Note that the plugin does not enable edit access per se. This means that if you want non-moderators to be able to collaboratively edit the post you must also make the post a Wiki (green, optional):

If I enabled Shared Edits, I have the option to make it a wiki, too. But if I do so via the Make Wiki option, it still reads “Make Wiki”. It will enter Wiki mode, though. But there is no way to revoke the Wiki.

Moderators can toggle shared edits on a topic (red) via the gear icon on the composer bar

I would like to see an option, where the right to start/stop shared edits is linked to the right to start/end a wiki. The functionality is quite similar, why choosing different rights (mods only)?

Now this is a critical one:

  1. I set a posting into wiki and shared edit mode
  2. Some people start editing away in the shared edit composer
  3. Some other people use the “classic” wiki editor - via the revisions link on the same posting at the same time:

and then at the bottom Edit Post

Now things get ugly real quick. Like - reeeealy ugly. Lots of overwritten stuff, changes not saved, revision conflicts. My understanding is, that shared edits is not designed to work at the same time as classic wiki editing (completely understandable from a technical view).

I figure the best way to solve this would be to redirect the Edit Post button to the new shared edits composer?

Hence the shared edits composer doesn’t offer the option to edit the metadata of the posting (titel, tags etc.), there has to be a solution for that, too.

One could argue “just tell your people to stay away from the revisions-pencil”, but this is not how it works - a lot of our users like this way instead of scrolling down to the end of a long WikiPad posting.

I see this might not an easy one to be fixed, but right now the shared edits feature is quite broken. We’ve tried it on several postings with different people, and always conflicts arose.


Any news on this? We “fixed” it by adding

div#revision-footer-buttons button:nth-of-type(1) {
    display: none !important;

to the CSS, but quite obviously this is a fix, not a solution…


Does it work the same now?

1 Like

You have articulated really clearly how the wiki functionality and the shared edits interact. And it isn’t pretty. Thanks for the workaround / fix!!

I rolled it into my little Wikified Posts Component as it is a nice little enhancement of wiki functionality.

1 Like

Ah - I didn’t knew about our Component, very useful (I just used the old one to color Wiki-posts and will switch now)