Beginner's Guide to Creating Discourse Plugins - Part 1


(dtbaker) #44

Cheers. solved here: Install a Plugin

Docker = Production. Vagrant = Dev.

(Ishan Dutta) #45

I am able to create plugin in development, it works fine. Thanks.
But I don’t see a way to install other’s plugin in development
So first question is how can I fork someone’s plugin in development and then build on top of that(hope copy paste that repo is not the recommended way)?
Second question is, it seems my created plugin is part of my repo, is there a way to create a separate github repo for the plugin automatically which others can directly use to install?

(Robin Ward) #46

I have a preferred method to do this. First, I have a ~/code directory where I have all my git projects. So I check out discourse and the plugin in that directory so it’s something like this:



Then, within the ~/code/discourse/plugins folder I create a symlink to the plugin:

$ cd ~/code/discourse/plugins
$ ln -s ~/code/discourse-some-plugin .

Then for good measure:

$ cd ~/code/discourse
$ rm -rf tmp
$ bundle exec rails server

Now you can fork the plugin in ~/code/discourse-some-plugin, make pull requests or whatever you want. It’ll be used by discourse.

(T1) #47

I am really confused by your documentation. You have a new pluginapi great! but no real example. All I want is to load a an Javascript and I can’t find a working example anywhere. After following the old guide, assets are not importing. New guide, doesn’t exist. Perhaps someone would be kind enough to walk us through this. I have no problems doing this in rails myself but I dont want to break future updates.All I wanted to do is load a 3rd party script and execute it.

(Mittineague) #48

Have you checked the source code from some of the existing plugins in the plugin category?

(Jay Pfaffman) #49

Wading through those plugins to figure out which one might include an appropriate example is not a trivial task. And you won’t necessarily know until you install a plugin whether it actually works with the new system.

For example my plugin needs to be moved to #plugin:broken-plugin.

It’d be really great if someone could fix Pirate Speak such that it’d work with the new plugin interface.

I pointed out that the plugin tutorial also doesn’t work, best I can tell and that the brand new plugin interface post from July 13 should be archived.

Hey, @erlend_sh, maybe you have some ideas here.

(Mittineague) #50

Fair point. Been there, done that. More times than I can count.

Not that it could be enforced or that any kind of formal “rules” could be established, but I guess if plugin authors included some kind of “summary” it might help those that have difficulty “reading” code.

(T1) #51

rm -rf tmp
Bad idea. Never ask newbies to do that. You will just end up breaking running processes.

(Mittineague) #52

Actually, AFAIK rm -rf tmp (or at least rm -rf tmp/cache) can be necessary

Otherwise the cached server side assets will be used and sometimes changes to the plugin being developed will not take effect.

What alternative approach do you recommend?

(T1) #53

Yes, exact files and directory or tmp must be specified. I am not sure what those are in this case but /tmp is shared by several system processes. I cam check today and post back with a list.

(cpradio) #54

But you took the above out of context. It is telling you to delete tmp out of the ~/code/discourse folder. It didn’t say to delete /tmp.

(Chris Beach) #55

+1 for the above concerns. IMO it’s not good enough to provide a collection of plugins in github as documentation. As a new Discourse plugin developer, I have no idea which of these plugins represents a good “canonical” example for doing things. And some of the plugins are really sophisticated - full of magic naming conventions and ES6 wiring that’s unfamilar to a traditional JS developer.

It’s so hard to identify magic naming conventions when all you have is a load of pre-made plugins to go on. Which words are keywords, and which words are arbitrary?

A few more canonical examples would go a long way.

For an experienced plugin developer these examples would take minutes to write.

For a brand new plugin developer these examples would save hours of frustrated clicking around.

A few questions I have in particular as a n00b discourse plugin developer:

  • Why are we using Vagrant for dev and Docker for prod?
  • How do I write a simple ES6 unit test? (not a whole acceptance test that requires a running Discourse instance). I got lost in a mire of gulp/grunt/phantomjs/babel etc. Surely there’s an easier way?
  • Is there a browser that I can run ES6 code in directly? If so, how? I know ES6 is still pretty new, but I can’t believe how little documentation exists on the web for this seemingly simple task
  • What’s the canonical way of writing a plugin that does a simple “replace this [keyword]params[/keyword] with something based on params”? I’ve tried a few different ways - none of them feel right

Stripe Payment (Form within post)
(Mittineague) #56

This does not need to be the case for development.

For example, I have a GitHub repository "test-plugin"
In my localhost Docker install I enter the app and edit the containers/app.yml file to install the plugin.

If all goes well the plugin doesn’t break the forum and I can then test it.

But before doing that, I test in my localhost Vagrant install to help ensure the plugin code is relatively bug free. I find it easier to work with Vagrant when my code causes a fatal error that I want to recover from.


Platform: Windows10

  • As mentioned above, bundle exec rails s -b works instead of just bundle exec rails server.
  • rm -rf tmp appears to work for PC on Windows PowerShell too.
  • For my case, as far as the “basic-plugin” mentioned in this post is concerned, I was able to see the changes in the plugin without re-starting the server. Just reloaded the browser tab and the changes were visible. Tested this on Chrome v53.0.2785.101 (latest at the moment). However, the tab does become unresponsive the first time it is reloaded after the change to the plugin has been saved, and has to be “killed”. The only thing different that I have from the default Vagrant environment is that I am using an updated gems version (v2.6.6). Is this behaviour to not restart the server, normal for such cases?


Can I just use DigitalOcean one-click discourse droplet for development of my plugin?

(Rafael dos Santos Silva) #59

For development you need a local setup: discourse/ at master · discourse/discourse · GitHub

(OG) #60

Thanks for this tip! Would you mind sharing your approach to transfering/managing custom code from dev to production install (Docker)? Is there any guide for this?

(Jay Pfaffman) #61

If you are going to make changes to your production Discourse, then you want to make those changes in plugins. Otherwise, it’ll be difficult to keep your changes integrated with Discourse upgrades (among other reasons).

(OG) #62

Of course, I am aware of that, sorry for not being clear enough… I was just curious about file management / git workflow that you are using when keeping number of custom plugins together with own extensions to them… (mainly regarding dev -> prod transfer)

Just to keep everything organized and easily synchronized with original upstream repos. I do have custom changes to plugins which won’t be pushed upstream.

Currently I’m just using single own repo for all the plugins when developing, because I hope I can transfer code to production later easily (I haven’t tested deployment to Docker container yet).

(Rafael dos Santos Silva) #63

You use one git repo for each plugin, that way you can install only the ones you need.