Plugin admin section

rfc
spec

(Sam Saffron) #1

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.


Closed Poll: How do you close a poll?
(Benjamin Kampmann) #2

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: )


(Jeff Atwood) #3

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


(Benjamin Kampmann) #4

From all I see, it only covers:

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


(Jeff Atwood) #5

Hmm, not quite, version information is also shown.


(Jeff Atwood) #6

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.


(Sam Saffron) #7

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


(Tom Newsom) #8

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.


(RBoy) #9

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

(cpradio) #10

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.