Plugin admin section

Problem

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.

  1. Add an extra tab to the admin screen that lists plugins
  2. Allow plugins to be enabled or disabled from the UI
  3. 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”
  4. A table needs to be added to track enable / disable state for plugins, by default anything missing from the table is enabled.
  5. UI should display which plugins are out-of-date (same way as discourse docker manager does it)
  6. Disable / Enable option to be suppressed for any multisite installs. (probably via a GlobalSetting)

Version 0 will not cover

  1. Upgrade logic for plugins via UI
  2. 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.

16 Likes

I’d love to implement this if someone else comes up with the mockups that we can agree on.

(Even would love to work on Version-1 if both installation and upgrade aren’t in this one yet :wink: )

This is in place for Discourse 1.2, not sure how many of the above cases it meets though.

From all I see, it only covers:

of Version 0. All else are missing. So we have an incomplete Version 0.

1 Like

Hmm, not quite, version information is also shown.

One thing that would be HUGELY useful here is an “enable / disable” button for each plugin.

Considering how many times the answer to a support question is “please disable all third party plugins”. It’s a lot. Like… a lot a lot.

Even a “safe mode” where all third-party plugins are disabled would be a massive help.

7 Likes

The tricky thing is orchestrating the coordinated restart of all the processes

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.

5 Likes

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:

  1. Simplify the plugin installation (and since it’s from the official list it’s easy to maintain)
  2. 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.

4 Likes

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.

1 Like