Cheers. solved here: Install a Plugin
Docker = Production. Vagrant = Dev.
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?
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.
Have you checked the source code from some of the existing plugins in the plugin category?
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.
It’d be really great if someone could fix Pirate Speak such that it’d work with the new plugin interface.
Hey, @erlend_sh, maybe you have some ideas here.
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.
rm -rf tmp
Bad idea. Never ask newbies to do that. You will just end up breaking running processes.
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?
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.
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.
+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:
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.
bundle exec rails s -b 0.0.0.0works instead of just
bundle exec rails server.
rm -rf tmpappears to work for PC on Windows PowerShell too.
Can I just use DigitalOcean one-click discourse droplet for development of my plugin?
For development you need a local setup: discourse/VAGRANT.md at master · discourse/discourse · GitHub
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?
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).
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).
You use one git repo for each plugin, that way you can install only the ones you need.