Discourse Shared Edits

Summary: Discourse shared edits allows multiple users to collaboratively edit posts in real time. This feature is default disabled and must be enabled explicitly by moderators on posts.

:link: GitHub: https://github.com/discourse/discourse-shared-edits
:arrow_right: Install: Follow the plugin installation guide.


Moderators can toggle shared edits on a topic (red) via the gear icon on the composer bar. 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):

Once toggled edits are collaborative. You’ll notice the button in the bottom left is now marked ‘Done’ is it is continuously saved in real time.


This plugin has a single site setting shared_edits_enabled it is default enabled after it is installed


  • Currently there is a ~10 second delay prior to updating the posts in the stream. It would be nice if this updated live just like it does in the composer.

  • Displaying multiple cursors would be nice, it would mean we need to replace the textarea with a contenteditable control or ace.

This plugin was inspired by @gdpelican’s collude but is a bottom up re-write so it fits better into the current Discourse designs.


Thank you @sam for this plugin. I’ve been waiting for it!

So today at our weekly team meeting we added a “testing shared edits” point to see how it fares against our beloved HedgeDoc. Here’s a quick report…

Overall Experience

First of all, a quick introduction to our weekly meetings. We are a team of 8 people from 6 different countries meeting once a week over Mumble and HedgeHog. Each week a Discourse topic is created, pointing to a structured pad that is used to announce the agenda and keep notes. Once the meeting is over, the notes are adjusted (adding link to the next pad, cleaning up stuff, usually benign edition at most), then copy-pasted to the original Discourse topic where they are kept. HedgeHog is beautiful and the highlighting helps a lot with the reading (if you can see colors that is) – I wish the Discourse composer would match this especially as it makes the task lists easier to go through.

As mentioned in the TODO, there’s quite a delay in updating, but it does not render it unusable: one has to be patient, but as we primarily use voice and the pad is mostly for guidance and note taking, it’s OK. We’re ready to do some more testing!

Bugs. Bugs?

We found one. I was looking for a cursor stealing issue but could not make one (yet), since this is the plague of instantaneous collaborative editors. No, the bug relates to the integration of Polls (so I suspect other bugs in composer extras to appear as well). Here’s a screenshot that demonstrates it:

The screenshot shows the composer with the preview, and the “live” result above. In the composer preview, the poll appears as it should, but the “live” result is not showing check boxes, rendering it useless.


Our team is not ready yet for a replacement of HedgeDoc with this plugin, but I can anticipate an upcoming change in dealing with our weekly meetings and Discourse: instead of using a chain of topics and a #meeting tag, I will create a dedicated meetings category with a topic template to “pre-populate” the original post and make it a collaborative editor by default (the way we can make topics wikis automatically).

That leads me to a reflection about integration of shared edits with other existing functionality:

  • when a category has “Make new topics wikis by default” it should also propose an option to turn on shared edits
  • maybe wikis should have shared edits turned on by default when this is ready
  • like with bookmarks, it would be interested to be able to turn on the shared edits feature for a period of time (e.g., a scheduled timer for meetings or classrooms).

And in the “later” category:

  • when using a topic template, once the topic is created, it could be nice to have this original part “locked” so that people can only edit under existing titles or add new stuff, but keep the rest untouched.

What we do in all our meetings is just have everyone click “Edit” once that is done updates are 100% live in the composer. Live updating in the topic html will happen eventually it is just a more complex change.

Polls is interesting, I never really considered this use case, will have a think.

Yeah agree this can certainly be an option the plugin introduces

Interesting idea.


@sam - great work. I’m guessing that this was ‘not trivial’ to produce! We’ll enjoy kicking the tyres over the next wee while too.

Hey, in our instance we style Wikis green to make them more obvious:

.wiki .topic-body {background-color: #effbfb;}

Is it possible to do this with Shared Edits too?


I am not sure if I have a special class set, but it is certainly a good idea.


I’ve encountered three issues:

Doesn’t work for non-moderators

When I test it, only moderators can actually do the shared edits.

This is not what I expected; I thought that while only moderators can toggle Shared Edits, once toggled any user with reply access to the topic should be able to collaboratively edit it. Just like the Wiki function.

Settings copy a bit scrambled

Icon and icon location in the composer gears menu is not ideal (minor point!)

If possible, it would be nicer to have it under the Make Wiki icon, with Rebuild HTML at the bottom. Also a similar but different icon would help.

1 Like

It works if you also make the post wiki to open up editing rights, though, correct?


Yes it does! I’ll edit the OP to make this crystal clear.


Does it work like Google Docs where you can see the other person editing in real time? Also, does it work with more than two people?


You can see other people typing but there is no support for multiple cursors yet


Does this mean that it is on the roadmap? Would be awesome!

1 Like

In my 5 year roadmap, I want to experiment one day with a rich text editor


I anticipate support for multiple cursors. :slight_smile:

1 Like

Out of curiosity, is there a reason that this plugin isn’t built into core?

1 Like

It is a complex plugin, we don’t want to carry this code in core.

1 Like

Ah, okay. That is understandable.

1 Like

This seems very useful but I wonder: how does this differ from wiki posts?

1 Like

Say if you have two people taking notes on a meeting, they can simultaneously edit the text of the post without running into version conflicts. Wiki posts are great for documentation or things that are edited by multiple people asynchronously, but there are certain use cases like the one noted above where having shared edits is useful.


Are there any scale constraints?
Like, would it have a bigger demand for concurrent users than the one the site has? should we accomodate extra capacity for it?


I have not tested this at “maxtreme scale” especially something like 10k users editing 1 document. Stuff is designed to rate limit and end up reconciling on a stable state.

I doubt you need any server changes just to install the plugin, but heavily depends on usage.