Wiki sync plugin

Development

AI-generated summary

Wiki Sync Plugin Discussion Summary

The discussion revolves around creating a Discourse plugin to sync wiki mode posts with an external Git repository. Lapinot proposed the idea, aiming to enable a simple workflow where posts are committed to the Git repository, triggering automatic builds of a static site.

Lapinot inquired about the feasibility of implementing this plugin, specifically seeking guidance on how to execute code server-side when a wiki mode post is edited. mpalmer acknowledged the idea’s potential usefulness, but noted that its ease of implementation depends on the developer’s perspective.

Overgrow suggested utilizing Discourse’s built-in wiki feature and API to present the wiki elsewhere, skipping the need for Git. However, Lapinot clarified that this approach wouldn’t work for their use case, as they need to feed the markdown files into a static site generator.

erlend_sh shared examples of similar setups, including the LearnDiscourse experiment, which faced similar limitations. Lapinot found these examples helpful and decided to take a closer look at Learndiscourse as a potential base for their plugin.

Alternative Approaches and Considerations

Overgrow questioned the need for a static site, suggesting that expanding the Discourse application using Rails and Ember.js could be a viable alternative. Lapinot explained that they prefer a static site for performance and security reasons.

Potential Breakthrough

Lapinot discovered a potential solution in the form of Discourse webhooks, which could provide a server-side hook for watching topic/posts edit events. This might be the exact feature needed to implement the wiki sync plugin.

1

Hi everyone, I had an idea of a simple plugin that I am going to write but I may need some help/advices.

The idea is just to sync up the posts in wiki mode with some external version control (a git server). This is really simple if there is a server-side discourse hook like after-edit-post or something similar but I can’t find it. My use case is that I don’t like CMSs but I need a collaboratively built website (kinda like a wiki) so I would like to have a automatically run static site generator on top of some git repo. The problem is that lots of people don’t know how to use version control systems and that we already have a healthy discourse instance. This plugin would enable a very simple workflow: just post a a mesage in wiki mode and it will be committed (as well as any subsequent edit) to the git repository in some directory depending on the category. From there it can be used for automatic builds of the static site (or could maybe also be used by a gollum wiki or any other documentation system).

I don’t think this kind of thing has already been developped and I am not very familiar with ruby so I couldn’t really find my way in the source code. Does this sound good and would it be easy to implement?

2

There have been wistful mentions of things like this before, but as far as I know nobody’s developed anything for public release. It sounds like it could be useful, and whether it’s “easy to implement” is entirely in the eye of the beholder… :grinning:

3

Thanks for the answer! Actually my question about easyness was not very clear… I meant: what do I have to do in order to get some piece of code called server-side every time a (wiki mode) post gets edited? Is there already a hook somewhere or do I have to actually make a pull request and fiddle with the core discourse code (add some code in discourse/app/controllers/posts_controller.rb)?

4

Are you aware that Discourse supports enabling “wiki” for selected posts? These posts are tracked for changes (there is even highlighted diff shown publicly)… (To be sure check for exact implementation - I don’t know about its limitations).

I don’t know if its good for your case, but I’d definitely use this core feature and just use Discourse API to present Wiki somewhere else… Then you can skip the git.

5

I mentionned it :wink: The problem with that is that I want to feed these markdown files into a static site generator (or something similar) so if I don’t have hooks and custom versionning, I wouldn’t know when posts have changed and I must regenerate the site. But maybe you’re right, I should just periodically scan for changes with the API and rebuild if necessary, it could be cleaner.

6

You can see an example of a similar setup here:

There’s also the LearnDiscourse experiment. You can get an idea of how it worked by reading the workflow doc. I think @fantasticfears who worked on the learndiscourse prototype ran into the same limitation you did, which is why we settled with

Your changes will be applied the next time we update learndiscourse.org, which usually happens at least once every week.

You might also run into this problem:

7

Why this needs to be static in the first place?

I’m working on something similar…

Using rails and ember.js you can just expand current Discourse application and build simple presentation model (wiki category >< post).

But of course its the matter of personal taste :slight_smile:

8

@erlend_sh Nice, I totally missed these topics while researching around meta.. Learndiscourse seems like the exact same thing I want to achieve, I will take a closer look and probably take it as base. It seems like querying discourse periodically with the API is the way to go.

@Overgrow The advantages of being static is that you have much better performance and security. And actually, my content is not going to change so often (I think one rebuild every day will really be enough). Moreover I am not really fluent in ruby (agreed, syntax is simple, especially coming from python) and really not used to frontend development.

Edit: I started doing some bot periodic scanning/watching of the topics with a python scripts using the discourse API but I just stumbled over this topic:

It might be the exact thing I want: some server side hook watching for topic/posts edit events.