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 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?
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 GitHub.com/discourse 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.
