Developing Discourse Plugins - Part 1 - Create a basic plugin

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.