I think what they are suggesting is that if a plugin that was already bundled with core was listed in app.yaml, then it would just be ignored. With a notification stating that including in app.yaml was redundant and the owner could remove it.
I too find it a little annoying that as long as I have any plugins listed in my app.yaml, I always run the risk of a failed update. So every time I do the update I need to double check to see if one of my plugins has been added to core.
Why not simply have a script that does it for the Sysop?
I myself organize plugins by team or author to make my life a bit easier so I know which plugins are official and such. But if the idea is to make discourse more user friendly that needs to be done on the team end.
Not really all that different when you counselled ppl when a user has a broken upgrade due to Postreq(so?) upgrade failure.
With plugins this is exactly where the concept of the Procourse Installed was a great idea for simplifying plugin install and uninstall without needing to use the command line
Granted I understand it maybe needed some more polish in event something went wrong. But that could be easy enough with a log file or a simple fallback if needed from the command line. I do appreciate that this might make it more appealing for self hosting vs a paid plan. However there are enough pros for a paid plan to still go that way.
This type of plugin manager could also be crafted or forked to allow hosted plans to install plugins within their hosted tier as some plugins may not be needed in the specific plan.
Indeed I missed a post long ago regarding chat being bundled and had tried to install it. I don’t think the tag was updated on the plugin. If course it crashed the site as it didn’t like trying to install the plugin when in theory it could simply have maybe ignored the entry with a completed rebuild advising it could be removed as it was unnecessary.
OK, feedback received! 
I think we can close this topic now - I’ll set a timer to give colleagues a chance to respond if they want to.
Will whos-online make it to core?
With the recent initiative to bundle more official plugins into core, I was wondering whether the Who’s Online plugin is being considered for inclusion.
I’ve noticed it’s available on the official hosting plans (counting toward plugin quota), so I’m curious if that indicates movement toward broader adoption.
Totally understand if performance constraints or philosophical fit mean it should remain off by default unless specific otherwise in the app.yml .
Thanks!
We don’t currently plan to move any more plugins into core. Cakeday was the last one, and had to be done separately to the main batch because of some complications with the way it was previously enabled-by-default.
Completely understand the frustration about the process here - it’s certainly not as smooth as I’d like. To give some context: the fundamental problem is that the app.yml files are not a Discourse config file. They are a pups config, and the plugin installation lines are just shell commands.
Bringing Discourse-specific logic into pups, and making it ignore certain shell commands, isn’t really an option. This tool isn’t just used for Discourse. Plus, I suspect a number of people would be unhappy to have us change the shell commands running during bootstrap without their knowledge.
So we landed on the cleanest solution we could find with the tools available: force a CLI rebuild, and then display a message asking people to remove the affected line from their config.
Interesting post, David!
I noticed something in the OP of the Who’s Online plugin topic:
Think carefully before installing this plugin
I think “installing” might be better phrased as “enabling” there - if that’s technically correct.
The current phrasing could give the impression that having additional bundled plugins present is a philosophical or performance concern - when it’s really only about whether they are enabled. Since a newly core plugin that wasn’t enabled before is disabled by default after rebuild, the risk isn’t in having it installed with core, but in turning it on.
That is not necessarily true, an installed but disabled plugin can indeed cause performance concerns, see for instance Disabled plugins still causing performance impact
Now that specific issue has been solved (for the most?) on the bundled plugins, but on other plugins this might still be happening here and there.
The discourse-categories-suppressed plugin adds a simple, optional UI to hide selected categories from the Latest feed. It integrates through a single dropdown in:
Admin → Settings → Categories
“categories suppressed from latest”
This feels like a very natural core setting — especially since:
• It’s official and actively maintained
• It remains disabled by default unless an admin opts into it
• Many communities (mine included) rely on “Latest” as the primary landing view and want finer control over what appears there
Would the team consider bundling this plugin (still disabled by default), so admins can use this toggle without needing to install anything extra?
Thanks for considering — it seems like a small UI preference that a lot of sites would benefit from having available out-of-the-box.