The discussion is focused on improving the /admin/plugins page in Discourse. Stephen suggests restructuring the plugins page to group core, official, and third-party plugins separately, and to indicate if a plugin has been merged into the core. HAWK mentions that there are no current plans for a major overhaul, but supports the suggestion.
Tgxworld adds a checkmark to official plugins in the UI. Codinghorror suggests moving the checkmark to a separate column on the left. The discussion then revolves around how to visually differentiate between core, official, and third-party plugins.
Stephen emphasizes the importance of distinguishing between core and optional plugins, especially for troubleshooting purposes. Tgxworld explains that plugins merged into the core are still considered plugins and should appear in the list. However, Stephen points out that this can cause confusion, especially when a plugin is still referenced in the app.yml file.
Codinghorror suggests that the situation is rare and can be handled with a support topic. However, Stephen and tophee argue that visually marking core plugins differently would be beneficial.
Tgxworld suggests using the /safe-mode feature to disable unofficial plugins, but Stephen points out that this does not address the issue of core plugins. Tophee suggests listing core plugins in a separate section or using a different icon.
Logan_Devine proposes using different icons to indicate the type of plugin. Tgxworld addresses some of the issues raised by Stephen, and codinghorror agrees to fix the lazyYT issue. TechAPJ commits the change to hide the lazyYT plugin from the /admin/plugins page.
Finally, eatcodetravel suggests adding plugin ordering, and codinghorror mentions that this is a known issue.
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?
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.
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.
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.
That’s great, but the site in question had GitHub - discourse/discourse-presence · GitHub 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?
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.
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.
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 Discourse · GitHub in the yml.
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.
