(Btw @Heliosurge I think this was brought up earlier):
It’s obvious that the topic has now completely veered off course, as always happens in any thread that goes against the grain. I don’t even intend to discuss the issue of using a theme component, but thanks to everyone anyway.
How did it veer off track? You asked a question and people expressed their opinions. Looks completely on topic to me?
You have all the info you need now to implement whatever setup you want?
I agree somewhat with OP that the “opinions” started to slide into “ridicule OP for what he wants”.
I don’t think this needs to be debated further. So unless someone has another solution to contribute to this topic, we can end the discussion here imo.
I do agree that some of the posts have unneeded aggressiveness.
I only mentioned a TC in regards to your adding a button to the home page. This has already been demonstrated by several components. If it is not a security issue a TC is the way to go.
Though I myself would be interested in what issues you have with Themes & Theme components? Plugins are more for security and things that cannot be accomplished within a TC - like changing how core functions. If your more comfortable we could discuss this in a friendly pm.
Another benefit of the TC is you could edit your code when needed within site web UI.
The problem I see with plugin route is that even official plugins merged in core still use Git to update the plugins & discourse itself.
You can use the volume support on the app.yml to mount a folder on the host to the plugins folder on the container.
You can use any way you want to copy your source code from wherever you keep it into the discourse/plugins directory. If you don’t like git clone you can use rsync or cp -a. Just copy your plugin to your VM any way you want and insert some command to copy it the way that git clone would.
This surely is the right answer here. It respects the original parameters of the question. This hasn’t been a great thread from the perspective of showing a positive and supportive community.
@Falco @pfaffman Thank you, your answers resolved my doubts.
I’m leaving my app.yml configuration here in case it’s useful to anyone trying to load local plugins into Discourse from the host machine.
## The Docker container is stateless; all data is stored in /shared
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log
- volume:
host: /var/discourse/plugins
guest: /var/plugins
## Plugins go here
## see https://meta.discourse.org/t/19157 for details
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- cp -a /var/plugins/. $home/plugins/
In my setup, I keep all custom plugins in /var/discourse/plugins on the host.
The mounted directory becomes available inside the container as /var/plugins, and during the after_code hook, the command:
cp -a /var/plugins/. $home/plugins/
copies all mounted plugins into Discourse’s native plugins directory ($home/plugins, typically /var/www/discourse/plugins).
This makes it possible to manage plugins directly from the host without using git-based plugin installation or relying on third-party hosting services.
Great. Glad that worked for you!
You could also symlink to the plugins instead of copy. And if you did, changes to them could be applied (at least in some cases where you don’t need to migrate or compile assets) by restarting the container.
Hi, just curious how do you handle migration and db changes?
Those are independent of how a plugin is installed. If the plugin is present, migrations will be handled.