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
Got it, your unusual set-up threw me.
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
If it’s just a js file, you can deploy that in a theme component.
Theme Components can be copied to a site, so long as it is accessible via https using the discourse_theme gem.
You can even use an existing remote production site for that purpose, no need to set up a local one.
See Discourse Theme CLI (console app to help you build themes) - howto / developers - Discourse Meta
It’s a js file of an existing plugin (namely the initializer) that I want to mod. Theme components doesn’t help (unless I misunderstand you)
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!
no problem.
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:
(credit @angus)
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.
Sounds like exactly that. You have a process running already on port 3000. Kill it.
lsof -wni tcp:3000 will list processes using that port.
Haha, as I said, I’m using it for something else, I can’t just kill it. Surely it shouldn’t be that hard to change the port (famous last words it seems)
Suggest you ask that on the linked topic, from my brief look at that script it looks hard coded, but could be wrong, the script might be built.
I noticed the hardcoded stuff too, yet there are references to a port config in yml files as well as ENV variables. I’m giving up on this for now. Way too much time invested already for what I wanted to test.
Spun up a VM with a fresh Ubuntu 22.04. The dev install craps out: Beginners Guide to Install Discourse for Development using Docker - #213 by nordize
Not my day … but definitely not minutes either (no pun intended). Thanks for your time, and sorry you had to waste it too.
@merefield quick question: is there a faster way to get plugin code updates in the container than doing d/shutdown_dev; d/boot_dev which takes ages and download a crap ton of data as it pulls docker images? Doing that every time I change a line of code to test in the browser seems utterly overkill even for a dockerized env
Restarting the rails server with d/rails s doesn’t see my plugin’s code changes.
This should only be necessary if you remove or add a plugin, not if you change a line of code.
If that line is Ruby or CSS it will hot load the new code. If Ruby you should see the unicorns restarting in the terminal iirc.
If it is javascript you just have to refresh the browser.