Improving /admin/plugins


(Stephen) #1

So I’ve been helping a couple of communities troubleshoot and tidy up their instances. In both cases some of that housekeeping involved removing broken and/or redundant plugins.

It was pretty straightforward for me to do, but that’s only because I’m reasonably in tune with the changes which have occurred over the past 12-18 months, so when I see plugins such as presence I know that it has since been merged into core (although the link from /admin/plugins still refers back to the original empty repo).

Are there any plans to restructure the plugins page as a part of the /admin overhaul? It would be great if plugins which are actually part of core (such as discourse-details, discourse-narrative-bot, discourse-nginx-performance-report, discourse-presence, docker manager, lazyYT and poll) were grouped separately, and if a repo which is known to have been merged into the current version is also still in the config maybe chuck up an alert?

While I couldn’t find a current example, I can’t discount the possibility that there be cases of plugins which still have a repo whilst also being merged into core so as to support older versions of Discourse. How is that handled by Discourse today? How are less engaged admins meant to identify plugins which become core functionality?


#2

Not at this point, no.

I support your suggestion though.


(Jeff Atwood) #3

It would definitely be good to give official plugins some kind of stamp in the UI here @tgxworld


(Alan Tan) #5

I added a check beside official plugins in


(Jeff Atwood) #6

Based on previous advice from @awesomerobot I think the check should be in its own column, on the left.


(Alan Tan) #7

Do we want it to the left of Name?


(Jeff Atwood) #8

Yes in a small narrow column with no header text.


(Stephen) #9

Looks good, but will we get any visual differentiation between official and core?

My point originally is that when troubleshooting one of the first steps is usually to look at plugins, so having something which denotes core from official from third party would be incredibly helpful. Particularly in the case I gave above where an official plugin made its way into core, but was still referenced in the app.yml of one of the sites I was investigating.


(Mittineague) #10

Right now they look to be more or less ordered alphabetically. My personal taste would be to separate them with a simple horizontal rule. But if ordering alphabetically is easier I think think the icons look good too. The main point is to distinguish the difference, minute details as to how it’s done is for bike-shedding.


(Stephen) #11

I was thinking of suggesting sections originally, but from there my thoughts meandered towards wondering whether stuff in core should appear in plugins at all. Sections would be great, but if we get to that stage it would also be great to remove stuff that isn’t optional, they really need another home.


(Mittineague) #12

Two rows of icons? Font family differences?


(Alan Tan) #13

Plugins that are part of the core repository are still plugins so it should appear in the list.

Fixed in


(Stephen) #14

That’s great, but the site in question had https://github.com/discourse/discourse-presence.git in the plugins section of the yml too. When a plugin makes the change from official to core how do sites know? How does Discourse handle it?


(Alan Tan) #15

I’m pretty sure ./launcher rebuild will fail requiring the user to remove git clone <plugin> from app.yml


(Stephen) #16

What about if they just update via /admin? It’s the kind of predictable change that could be handled more gracefully, alerting the user via /admin that a plugin is moved into core to avoid failed rebuilds and support requests here on meta.


(Jeff Atwood) #17

Based on observed data, probably not worth the effort. Rare situation, easily handled with a topic here to refer people to. No need to gold plate it.


(Christoph) #18

I do agree, though, that it would help to gave those core plugins presented differently (maybe another icon?). After all, they cannot be removed by the user, right? and therefore don’t feel like plugins, even if they technically are plugins.


(Alan Tan) #19

What benefits would we get by visually marking core plugins differently?


(Stephen) #20

For one it lets anyone troubleshooting their instance tell immediately whether they have any plugins installed.

Admins who are less familiar won’t know that the term plugin is being used to describe something other than optional code modules.

Usually to troubleshoot we would disable third party plugins, then official. Right now it’s hard to distinguish between something in core and something referenced from GitHub.com/discourse in the yml.


(Alan Tan) #21

You won’t need to distinguish that at all since you can just go to /safe-mode and choose to disable unofficial plugins. If that doesn’t work, you can then disable all plugins.