Disable plugins without restarting?


(Ken Cooper) #1

I’m finding Amazon oneboxes are failing to expand on my production server, but they work on meta.discourse.org, and on my dev site. I’m thinking it’s likely a conflict with discourse-affiliate or discourse-adplugin. I’m able to ‘soft’ disable discourse-affiliate, since it has a setting, but I’m not sure that’s trustworthy in testing this, and there isn’t one for discourse-adplugin.

Restarting with launcher is very obtrusive at this point, probably a 20 minute down time. Is there a way to disable plugins without this? Don’t mind ssh if it’s relatively bullet proof.


(Mittineague) #2

You’re not testing in a non-live site?

Anyway, AFAIK disabling a plugin means it won’t “do its thing” but as Discourse compiles plugin code a lot of it may still be causing conflicts.
The only sure way I’ve found is to uninstall (remove) the plugin then rebuild


(Ken Cooper) #3

I am testing in a non-live site, but was doing so without those plugins for various reasons. I am now adding them on the non-live site to see if I can replicate it.

I understand what you mean about the code’s presence alone being enough to cause problems. What I guess I’m wondering is if there’s a way to only partially rebuild that isn’t so costly in time. I can, for example, update to new versions of git hosted plugins from the docker manager; is there a way to remove a plugin using this same execution path?


(Joe Seyfried) #4

You could also do a

RAILS_ENV=production rake assets:precompile

in the /var/www/discourse directory if you’ve SSH’d in, and then do a

sv restart unicorn

…that should be much faster. You can move plugins in and out of /var/www/discourse/plugins, which should do the trick…


(Ken Cooper) #5

Exactly what I was looking for. Thanks!


(Sam Saffron) #6

Note, rake is a shell script that takes care of env in the docker container, no need to specify it again