Developing Discourse Plugins - Part 1 - Create a basic plugin

:thumbsup: for raising an error instead. Maybe we can extend that to development too? :thought_balloon:


Hopefully this will prevent others from making this mistake:



Is this url correct? Shouldn’t this be ,

I’m new here. please correct me if im wrong :slight_smile:

In Discourse, mainly there are two big JavaScript sections “discourse” and “admin”. Also you can see few more in

In plugins, to differentiate admin & normal user section JavaScript files we use “discourse” and “admin” keywords in between like below


Also it will just work even without identification keywords like you mentioned :slight_smile:


@vinothkannans Thank you a lot for the explanation. :slight_smile:

I’m experiencing the same issue with getting symlinks to work (I’m on Linux) - the ln -s appears to work, but from inside the docker container the path is inaccessible. The plugin works when it is directly copied into the plugins folder, but I like the symlink workflow as it enables a more sensible Git arrangment.

This SO question appears to suggest that symlinks won’t work this way unless we also add the linked-to plugin volume to the docker run command Mount host directory with a symbolic link inside in docker container - Stack Overflow

Anyone any thoughts on this? What are the pro plugin developers doing for a sensible Git workflow?


I’m using symlinks but my dev setup is Docker-frei.

Symlinks are a really nice way of being able to include or exclude plugins on a ‘build’ very quickly without disturbing the codebase.


Here’s what I’ve had to do in order to preserve a similar workflow to using symlinks (softlinks):

I edited /bin/docker/boot_dev in Discourse (outside the container) so that the plugin I want to work on is added as a volume and mounted in the /src/plugins/ directory (inside the container).

In my case it looks like this:

docker run -d -p 9405:9405 -p 1080:1080 -p 3000:3000 -p 9292:9292 \
-v "$DATA_DIR:/shared/postgres_data:delegated" \
-v "$SOURCE_DIR:/src:delegated" \ 
-v "/home/marcus/code/discourse/discourse-reflective-learning-plugin:/src/plugins/discourse-reflective-learning-plugin" \
$ENV_ARGS --hostname=discourse --name=discourse_dev --restart=always \
discourse/discourse_dev:release /sbin/boot

I’ve used absolute paths because I couldn’t be bothered to get into relative paths inside Docker and $SOURCE_DIR environment variables, but I’m sure there’s a cleverer way to do this, so that perhaps all your plugins could be in directories at the same level as discourse and it would automagically include them all. Hope this helps someone.


I am totally open to a PR that automatically follows symlinks in plugins/ dir and then smart mounts volumes.


Hmmmm. That’s a tricky one, because the symlink needed to be deleted, otherwise the Docker mount fails (as it cannot overwrite the existing file).

I had a bit of a google around for solutions, and found an interesting solution which would dereference the symlink and copy the symlink’s target into the specified directory, but couldn’t find anything that would create a Docker volume mount, thus preserving the dynamic link and bi-directional synchronisation. Happy to be steered towards a solution as this would be a neat feature to have.

Tell me how to add your validation to the app/models /user.rb model?

1 Like

You can use regular Ruby code to do this in your plugin.rb:

class ::User < ActiveRecord::Base
  validates_presence_of :your_attribute

Just starting on my first small plugin :blush: I have a few questions I hope someone can help with…

First question is does it matter if we use what’s in this guide or should we really be aiming to use the plugin generator?

It wasn’t covered in this guide, but how can we make data available to our templates from the plugin.rb file?

Let’s say for example I want to display a random welcome message at the plugin-outlet topic-above-posts whenever somebody visits a topic, with the message being randomly selected from an array in plugin.rb… how would I send that data to the template? Which I also presume would go here:

plugins/my_new_plugin/assets/javascripts/discourse/templates/connectors/topic-above-posts/my_new_plugin.hbs (Is this correct?)

Any tips greatly appreciated :blush:


Using the plugin generator is generally a great way to get started and see how a plugin should be structured. I recommend it.

Now, regarding how to get ruby code into the front end: those are two different applications. The front end application (Ember) will have to request it from the server (Rails) somehow. Normally we do this via an AJAX call, but you could also do something like add to the SiteSerializer so that it’s sent automatically as part of the forum data.

Otherwise you will have to look up how to add a route/controller in rails and send the messages as JSON.


Thanks Robin!

Would you know if there are any tutorials on this? Or, is there a simple plugin (or even a dummy plugin) we can look at that points us in the right direction? (If not, is this something you could quickly put up for us somewhere please? I think it’ll help a lot of people :blush:)

Plus… any more thoughts on writing a book? I can put you in touch with someone if you fancy it :smiley:

1 Like

Thanks for the compliment but I’m definitely far too busy to consider writing a book. Plus tech books have SUPER limited range. Those I know who have written them say you do it for yourself, not for the money :slight_smile:

I can’t think of simple plugin for returning something from the server side. discourse-tooltips adds a route and then uses that to get previews of topics as you mouseover so that might be helpful.


Soon, I will start plugin development…


Is there a list of hooks where we actually can plugin?

For example, say we want to write a plugin to process the cooked data in a post before it is displayed, we would expect there to be at least one hook at the beginning and one at the end, like (for example):

  • display_post_start

  • display_post_complex

Then, our plugin would hook into the code at the hook location of our choice above.

Is there a list of these plugin hooks and what are these plugin hooks called in DiscourseWorld?

Update: Found this:

git grep "plugin-outlet" -- "*.hbs"

But there was no outlet for modifying cooked post content, that I can see.

Is there a tutorial on creating our own outlets, for example, an outlet to modify the cooked part of posts?


You’re looking for this guide, section decorateCooked():


I use this skeleton for a custom plugin. Do I need to change anything for the upcoming Ember 5 transition?

I suppose not? Although this is just a linter?

1 Like

The skeleton is compatible with Ember 5. But if you added any javascript code or hbs templates, you’ll need to check for deprecations as described in the announcement.

Yeah the stuff in package.json is just related to linting, it doesn’t affect the functionality or compatibility of a plugin.