At the moment, short of using discourse docker plugin there is no place to list the current plugins, install plugins or disable plugins in the admin UI.
It makes diagnosing issues sometimes tricky, staying up to date with plugins and so on.
Version 0
Version 0 of the admin plugin UI will be VERY simple.
Add an extra tab to the admin screen that lists plugins
Allow plugins to be enabled or disabled from the UI
If a plugin is disabled/enabled a restart of Discourse is required. This should be tracked, eg: display “Your plugin was disabled but will not be deactivated till you restart Discourse”
A table needs to be added to track enable / disable state for plugins, by default anything missing from the table is enabled.
UI should display which plugins are out-of-date (same way as discourse docker manager does it)
Disable / Enable option to be suppressed for any multisite installs. (probably via a GlobalSetting)
Version 0 will not cover
Upgrade logic for plugins via UI
Installation of new plugins or plugin discovery.
Since this involves UI, no work to be completed prior to UI mocks
Long term I envisage this deprecating GitHub - discourse/docker_manager: plugin for use with discourse docker image , instead what docker manager will do is simply implement various hooks like “this is how you restart discourse hook” or “this is how you install a plugin hook”. Cross machine restarts get tricky, installation in Docker environment is tricky.
God yes. Especially when a general update breaks a plugin, it would be great to quickly turn it off rather than break out a command line, edit app.yml and do a rebuild.
Suggestion: Since there is an official list of plugins available, why not make an Install plugin button which retrieves from the list of official plugins and then automatically updates the app.yml file and triggers a rebuild (like what /admin/upgrade does).
This would achieve 2 things:
Simplify the plugin installation (and since it’s from the official list it’s easy to maintain)
Build in login to avoid conflicts, if a plugin moves from plugin status to core or something else, essentially official plugins can be handled gracefully and “managed” to avoid upgrade, change of state, deprecation etc situations
IIRC, the app.yml is outside of the container and thus not directly accessible to Discourse. The Discourse software itself is sandboxed in the docker container and therefore cannot alter the app.yml in any way.
As I noticed the chat plugin isn’t working on my site, I’d love to turn off all plugins that were not the chat plugin to 1) see if that fixes the problem and thus means there’s a plugin clash and 2) if so, then start to one-by-one turn on plugins to figure out which one is causing the problem.
Right now, with safe mode I can only turn off all third-party plugins or all plugins, which doesn’t give me the granularity I’d hope.
I can still disable/enable (almost) every plugin from its settings menus, and yet it takes a while, I think it’d just be easier to have a plugin enable/disable checklist also on the safe mode page, would make it so much faster.