Improving /admin/plugins


(Christoph) #22

Just to make sure I understand: is it possible to disable all plugins (i.e. all plugins listed on the plugin page)?


(Stephen) #23

No, only third party and official. The plugins page includes stuff which isn’t a plug-in in the sense that it’s included in the yml and can be commented out/removed such as docker-manager.

Maybe the solution is a second icon to indicate which plugins are loaded from the yml, rather than part of the base install?


(Christoph) #24

I still don’t understand why plugins that can’t be uninstalled are called plugins (and not modules or something like that), but I suppose there is a reason so, yes, I think that looks like a good compromise. Or instead of an icon, they could be listed in sub-section of the page (“Core-plugins”), or something like that.


(Stephen) #25

I queried that:

Either I didn’t explain myself well enough to @tgxworld or I’m missing something. From my perspective though it’s not a plugin if it can’t be unplugged.


(Alan Tan) #26

You can “unplug” it be disabling the plugin.


(Stephen) #27

H ow do you disable it if it’s not referenced in the yml and doesn’t have any settings?


(Alan Tan) #28

Which plugin are you referring to that doesn’t have any settings?


(Stephen) #29

These three aren’t in the YML and don’t have a settings button in /admin/plugins:

And will Discourse build with docker_manager disabled?


(Mittineague) #30

I guess you do have a point. Now that the settings for poll are under site-settings

it could be removed from the list under plugins if it makes much difference.


(Stephen) #31

I think the point we were driving at a month ago is that /admin/plugins contains more than plugins referenced from the YML. Right now we have:

  1. core code
  2. plugins which ship as part of core and can’t be disabled
  3. plugins which ship as part of core and can be disabled
  4. discourse-maintained plugins
  5. third party plugins

2,3,4,5 all appear in /admin/plugins

Some of 2/3 are in the yml, docker-manager for example, but would you ever want to disable them?

To new users 1, 4, and, 5 are pretty common. Compared to something like WordPress which ships with plugins such as Akismet, which can be both disabled and removed. 2 and 3 are a tad unfamiliar and step outside the typical definition of a plugin.


(Logan Devine) #32

I think having it like this would be optimal for admins:
No Icon: installed/3rd party plugin(s)
Green check: default plugin(s)
Golden square with the letter C in it: core plugin(s)


(Alan Tan) #33

For poll and discourse-nginx-performance-report, it is just a minor UX issue where the settings button are not being displayed. I have fixed that in

lazyYT doesn’t feel like a plugin to me if it can’t be disabled cc @techAPJ

docker_manager adds on a web interface to make it easier to manage a Discourse instance. Whether Discourse builds or not isn’t affected by the plugin.


(Jeff Atwood) #34

We should fix the lazyYT issue @techapj, I agree it is not a plugin, it is default behavior.


(Arpit Jalan) #37

lazyYT plugin will not be visible on /admin/plugins page anymore.

Thanks for adding the ability to hide plugin from /admin/plugins page @tgxworld. :+1:


(Orlando Del Aguila) #38

One thing I would love to see is plugin order. I’m working in heavily customized Discourse instance with plugins and we have a “base” plugin that includes most of our CSS stuff, and this plugin needs to be loaded first due variables, functions, mixins, etc.

Right now are are just using naming, since plugin uses ruby’s File class to load the directory, and these are sorted by name by default.

I’m pretty sure this is a weird use case, but if It’s something you would like to see merged, I may be able to put some work on it


(Jeff Atwood) #39

We’ve run into the ordering issue before, for sure.