Improving /admin/plugins

Feature
22

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

1 Like
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?

1 Like
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.

2 Likes
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.

1 Like
26

You can “unplug” it be disabling the plugin.

2 Likes
27

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

28

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

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?

2 Likes
30

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

https://github.com/discourse/discourse/blob/master/plugins/poll/config/locales/server.en.yml#L17-L22

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

1 Like
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.

1 Like
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)

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.

10 Likes
34

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

5 Likes
37

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

https://github.com/discourse/discourse/commit/69693f89f5b607fb27415d44bc4dd1946a354b63

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

3 Likes
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

3 Likes
39

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

2 Likes