Meer populaire plugins bundelen met Discourse core

[one1]

@tobiaseigen

in this case I’m not sure what could have been done differently

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.

[Heliosurge (Dan DeMontmorency)]

@tobiaseigen

Hey sorry you are unhappy about the path we chose but this is the way, unfortunately for you. The instructions are clear enough in my opinion and all you need to do is remove a few lines from your app.yml and rebuild, and you’re done

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 Installer 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.

[Heliosurge (Dan DeMontmorency)]

@one1

@tobiaseigen

in this case I’m not sure what could have been done differently

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

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. Of 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.

[tobiaseigen]

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.

[Ethsim2 (Ethan)]

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!

[david (David Taylor)]

@Ethsim2

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.

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.

@tobiaseigen

Point well taken that we can do more to make future changes like this easier.. in this case I’m not sure what could have been done differently because a change was needed in app.yml, which has to be done by the self-hoster at the command line.

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.

[Ethsim2 (Ethan)]

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.

[RGJ (Richard - Communiteq)]

@Ethsim2

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

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.

[Ethsim2 (Ethan)]

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.

[mentalstring (Paulo)]

@Moin

For everyone who is not tracking edits on the first post:
cakeday was moved to core

I’m not sure if this is intended, but wanted to report it:

We are on an outdated stable v3.5.4 and were using the cakeday. plugin. However, rebuilds (of the same Discourse version) stopped working because cakeday had been merged into the core. So, I disabled the plugin on the yml file and… well, it’s gone. Now it builds again, but we no longer have cake days as the admin UI shows no sign of the functionality being installed.

I’m guessing it’s because we are on a outdated stable version, but was still an unexpected result for a rebuild of the same version of Discourse.

[david (David Taylor)]

The cakeday plugin isn’t bundled in 3.5.4, so that’ll be why you’re not seeing it any more.

@mentalstring

However, rebuilds (of the same Discourse version) stopped working because cakeday had been merged into the core

Are you sure that’s why they started failing? If you saw something like:

HINT: The plugin ‘$plugin’ is now bundled with Discourse and should not be included in your container configuration

then I’m afraid that will be shown for any failed rebuild when the cakeday plugin is included in the config file. This was the most efficient way we could warn people about the issue, but it can be confusing for people running older core versions.

So if you need the cakeday plugin, I think you should be able to re-add it to your app.yml file and rebuild. I suspect the failure was caused by something else, which you’ve now resolved.

As an aside: I’d strongly recommend upgrading to a supported version. 3.5 is not receiving security updates any more, and may be vulnerable to attack.

[mentalstring (Paulo)]

@david

Are you sure that’s why they started failing?

Looks like it:

Cloning into 'docker_manager'...
I, [2026-03-09T15:05:49.126710 #1]  INFO -- : > cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git
fatal: destination path 'discourse-cakeday' already exists and is not an empty directory.


FAILED
--------------------
Pups::ExecError: cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git failed with return #<Process::Status: pid 146 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in `spawn'
exec failed with the params {"cd"=>"$home/plugins", "cmd"=>["git clone https://github.com/discourse/docker_manager.git", "git clone https://github.com/discourse/discourse-cakeday.git", "git clone https://github.com/discourse/discourse-whos-online.git", "git clone -b no-regional-flags https://github.com/mentalstring/discourse-nationalflags.git", "git clone https://github.com/discourse/discourse-yearly-review.git", "git clone https://0fa273b19b56a1a58c41484d49a01d99f1b5b8d2@github.com/mentalstring/custom-username-validator", "git clone https://github.com/discourse/discourse-saved-searches"]}
bootstrap failed with exit code 128
---
HINT: The plugin 'discourse-cakeday' is now bundled with Discourse and should not be included in your container configuration.
Remove the line 'git clone https://github.com/discourse/discourse-cakeday' from your containers/web_only.yml file, then try again.
For more information, see https://meta.discourse.org/t/373574
---
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.

@david

So if you need the cakeday plugin, I think you should be able to re-add it to your app.yml file and rebuild. I suspect the failure was caused by something else, which you’ve now resolved.

Re-adding the plugin to app.yml causes the error above. Removing it immediately makes the build work again. This plugin seems to be the only issue.

I’m aware we are on a outdated version and it’s on the roadmap to upgrade. Just wanted to point out that, although we have not changed the version we are running, 3.5.4 went from building fine (with the plugin) to no longer building with the plugin and we don’t seem to have any way to get the plugin functionality back (through plugin or in core).

[david (David Taylor)]

Interesting! I wonder if it’s because our docker image now includes discourse-cakeday, and then when core is “downgraded” to 3.5, it leaves an empty directory behind.

If you add rm -rf discourse-cakeday before the git clone https://.../discourse-cakeday line, then that should clean it up. So it would look something like:

hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - rm -rf discourse-cakeday
          - git clone https://github.com/discourse/discourse-cakeday

[mentalstring (Paulo)]

Yep, that did it. It’s working again — thank you!