I have a standard (edit: non-dev) docker install in /var/discourse. Is it possible to use a local plugin directory to load in Discourse instead of linking to a remote github repo from app.yml? If yes, how?
I tried two methods that I thought should be working:
Cloned discourse-math from github into /var/discourse/plugins/discourse-math. launcher rebuild said nothing about discourse-math and there is no discourse-math in the docker mount either, nor in the GUI. So I guess the plugins folder is ignored?
I also tried cloning into a different dir outside of /var/discourse and symlink-ing it to /var/discourse/plugins/discourse-math … same outcome.
Cloned the github repo in /var/discourse-math.git and edited my app.yml to say - git clone file:////var/discourse-math.git but then launcher rebuild complained fatal: '/var/discourse-math.git' does not appear to be a git repository … supposedly the launcher runs this in a docker container already? Manually running cd /tmp && git clone file:////var/discourse-math.git works just fine.
Right, yes, I was aware of the dev install, but I have a standard docker install (i.e. non-dev install), so I guess my question is still standing: can I sideload a plugin from a local directory or only remotely from github via app.yml?
p.s. I’m well aware the “correct” flow is to to have a dev install and play there. I wanted a quick and dirty way to mod and test a plugin instead of going through the entire pain of a dev install and setup
The production install will clone plugins into the container, so this is not suitable for local plugin development as for that workflow you will need to upload your changes to github.
My suggestion is junk that setup and use one of the two major dev options, docker or non-docker.
Just to make sure I got you correctly: You are referring to it cloning remote github plugins, and not able to clone from a local directory, even via github file:///? I take it that launcher.sh at that point runs in a container and not in the host, i.e. clones from github while in the container, instead of cloning from the host into the host’s mounted folder … which would allow me to git clone file:///…
If you want to turn the production install into a Frankenstein that is able to access the local mounted directories, you will need to change the build scripts to give it that access. You would need to be responsible to support those customisations yourself.
imho you are just creating work and fragility for yourself.
the docker dev install is precisely designed to give you a low maintenance solution for efficient local plugin development, please consider using it.
I know, and you’re right, of course. It was for a simple change to test in a javascript file of a plugin. I edited it straight in the container (/var/www/discourse/public/assets/plugins/discourse-math-.js) but for some reason, my edits are not reflected in the browser - the browser sees the old file, despite cleaning cache, presumably because the plugin js files are cached by the embedded nginx or something (?).
I’d be grateful for a tip for a way to edit a current js file in the container (as cringy as it sounds) and make it visible by the browser.
I might have already ended up in the “Didn’t have the time to write a short letter” teritorry … I didn’t have the time to go on the proper route of a dev install and I didn’t expect it to be this hard to mod a js file inside the container (little time to read up on how Discourse caches plugin js files to make my changes visible in the browser), etc etc
Theme components are loaded last, I believe, so will override the plugin.
Another good option is just to fork the plugin, clone it locally to amend and test it using a local dev install ( ). Once happy, commit and push it to your fork and use the fork for production.
However, the Theme Component solution has the advantage that you don’t have to maintain a fork which might become a pain as the parent plugin evolves.
Not sure a Theme component helps when I need to mod a file like this … that file (along with others), as i understand, goes through the mapper etc, to produce the container’s /var/www/discourse/public/applets/plugins/discourse-math-<id>.js file that the browser loads. I only need to change the latter, but the browser still sees the old file, as if there was server-side caching.
The local dev install is time and hassle consuming but may do it if all fails. I didn’t expect a dirty mod of a plugin js to be so painful. I also still don’t understand why my direct edits aren’t visible in the browser, unless there is server-side caching in the container’s nginx (no idea why given it’s a js)
Anyway, the time i had to look into this today is up :(. Thanks for help regardless!
Can’t get too deep in the specifics of what you are trying to achieve but in order to ensure an initializer runs after another, use this after: parameter, example:
The dev tooling has evolved for exactly this purpose, so if you can, use it. Setup of the dev docker environment should take minutes, not hours and you should only need to do it once, then it’s useful for all sorts of purposes subsequently. Don’t be tempted to use the production install locally only because you are familiar with it! It’s simply not configured for that purpose.
Call me stupid but how do I change the default port 3000 to something else? d/boot-dev --init fails as I’m using that port for something else. I tried -e UNICORN_PORT=4200. The guides I’ve seen say nothing about the port. The thin.yml file in config/cloud/cloud66/files seems to be ignored too
3000 is the Ruby server port and 4200 is the ember port. Both processes need to be running. You access the site in the browser via 4200. Better discuss the dev docker install in the dev docker topic?
Well, d/boot_dev --init fails (Error starting userland proxy: listen tcp 127.0.0.1:3000: bind: address already in use.). Maybe I’ll take this further later. Thanks for your time. I wish these things were better documented.
). Once happy, commit and push it to your fork and use the fork for production.