Meer populaire plugins bundelen met Discourse core

[Stephen]

Als de foutmelding aangeeft dat reactions, data explorer en solved nog steeds in je yml-bestand staan, dan is dat waarschijnlijk ook zo. Als je denkt dat je ze hebt uitgecommentarieerd, is het mogelijk dat ze dubbel zijn ingevoerd?

Het is zeker de moeite waard om de configuratie te bekijken en ervoor te zorgen dat je het yml-bestand hebt bewerkt dat bij je site hoort.

[evenlo]

Hi

I have successfully upgraded my forum to the latest 3.4.6 stable version. Prior to this, I was using the standalone discourse-oauth2-basic plugin for authentication.

There is no Oauth2 Basic login in the /admin/plugins.

My discourse version is 3.4.6.

HINT: The plugin ‘discourse-oauth2-basic’ is now bundled with Discourse and should not be included in your container configuration.
Remove the line ‘git clone GitHub - discourse/discourse-oauth2-basic: A basic OAuth2 plugin for use with Discourse’ from your containers/app.yml file, then try again.
For more information, see Bundling more popular plugins with Discourse core

I have to remove plugin discourse-oauth2-basic plugin before upgrade to 3.4.6

Could you please help me understand what might have gone wrong?

• Did I misunderstand the process, and is the plugin still required?
• Is there an additional step I missed to enable the core OAuth2 functionality after removing the plugin?
• Or am I simply looking in the wrong place for the settings?

Thank you!

[NateDhaliwal]

Hmm… zou het kunnen dat je op stabiel zit?

[evenlo]

Nadat ik de systeemprompt heb gevolgd, heb ik de discourse-oauth2-basic plugin verwijderd voordat ik succesvol heb geüpgraded naar de 3.4.6 stabiele versie.

Echter, ik heb nu ontdekt dat de configuratieopties voor OAuth 2 Basic ontbreken in het admin dashboard.

[david (David Taylor)]

Als je op stable zit, dan is niets van dit onderwerp van toepassing tot na de volgende stabiele release begin augustus. Je zou oauth2-basic dus terug moeten toevoegen aan je app.yml. De oorspronkelijke fout moet om een andere reden zijn geweest.

Helaas is de ‘hint’-logica niet erg slim en is deze zich niet bewust van stable versus tests-passed.

[eisammy (Sammy)]

@SkyeDragon

Sou contra esta mudança. Normalmente, no desenvolvimento de software, ter um núcleo enxuto significa que a distribuição principal pode ser menor, mais rápida e ter menos superfície de ataque.

Me too but What we can do about this right? lol I think that more native resources aka plugins even disabled it’s not a good solution to help beginners to there will self-host.

[eisammy (Sammy)]

@nat Kijk dit, mijn citaatvertaling en mijn antwoord

[bayardo.rivas]

Het maakte niet uit hoe ik probeerde de kloonregels in de pluginsecties uit te commentariëren, maar het las die regels alsof ik de plugins wilde installeren. Wat heb ik gedaan? Verwijder de regel en het werkte eindelijk.

Wanneer je een upgrade uitvoert, moet je de lijst met plugins controleren die in de kern van Discourse zijn opgenomen om deze niet toe te voegen aan de pluginsectie om te installeren of die regel te verwijderen als je deze in je app.yml-bestand hebt staan.

[Heliosurge (Dan DeMontmorency)]

@hellekin

I agree that this brings extra bloat in the admin interface, with a lot of brand names that account for as advertising to my brains. This is not cool. As a free software advocate trying hard to avoid big brands

I think as these are Pre Installed. There should be options that seperate these from the installed List. As the Installed list are removable vs only being abled to be disabled.

Maybe for core merged plugins should be under something like Featured plugins. Or Core Plugins.

With of course maybe an All filter.

[SkyeDragon (Skye)]

@eisammy

What we can do about this right?

Their suggestion is not ideal, but it does work. Example:

## Plugins go here
## see https://meta.discourse.org/t/19157 for details
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/pfaffman/discourse-allow-pm-to-staff.git
          #- git clone https://github.com/discourse/discourse-hcaptcha.git
          #- git clone https://github.com/discourse/discourse-calendar.git
          - rm -rf discourse-adplugin
          - rm -rf discourse-affiliate
          - rm -rf discourse-ai
          - rm -rf discourse-apple-auth
          - rm -rf discourse-assign
          - rm -rf discourse-login-with-amazon
          - rm -rf discourse-lti
          - rm -rf discourse-microsoft-auth
          - rm -rf discourse-patreon
          - rm -rf discourse-subscriptions
          - rm -rf discourse-zendesk-plugin

(Tune as desired)

[RGJ (Richard - Communiteq)]

@SkyeDragon

there is no LTS. The stable branch is actively recommended against using.

The reality here is that the stable branch is an LTS, and a pretty good one as well. It receives security updates and it’s pretty clear which plugin versions are compatible with it (thanks to the .discourse-compatibility file). I will totally admit that it took a long time before this all started working out, but in the past two years or so, it has - which is a great accomplishment by the team.

Now for the second part of your statement. It’s indeed the case that stable is often represented as something you shouldn’t want. But on Communiteq hosting, we have been giving clients the free choice between stable (“stability first, new updates twice per year, security updates once per month”) and tests-passed (“always on the edge, new features once per month”) for the past 2.5 years and 85% chooses to be on stable.

@david

it’ll be easier for us to keep them all tested & up-to-date.

@j.jaffeux

• we don’t have to worry about versioning if we add something in core for a plugin, we know that both of them are at the same version
• easier to test a plugin depending on another plugin if the code is present for both
• when we change something in core we often have to do multiple PRs just to fix specs in plugins, now it means only one standalone PR

I get that. But isn’t that a dev issue and not a production issue? I can totally understand that you’re doing this in dev. But adding those plugins in a default production install kind of defeats the idea of having a plugin (which is something not-default by definition).

The only actual production benefit that I see is the very, very edge issue of uninstalling plugins and multisite hosts. (Again, this is a good thing, all other production issues have been resolved over time!)

@david

The motivation here is to to provide a smoother experience for first-time users of Discourse, so that they get a more “fully featured” Discourse experience right out-the-box.

That could have also been resolved in the setup script by showing a list of plugins that users can check and then adding them to app.yml

@david

The plugins we’re merging here are the ones which we run on every single instance of Discourse on our discourse.org hosting

But you’re still offering different (sub)sets of plugins for different tiers, right?

[merefield (Robert)]

Ik had de voorkeur gegeven aan de app.yml uncomment benadering.

[sam (Sam Saffron)]

@RGJ

But you’re still offering different (sub)sets of plugins for different tiers, right?

All these plugins are installed on all our self-serve plans. Some tiers do not have access but they remain installed even if they don’t have access.

---

We are not changing this decision, so this is simply something people are going to have to live with. I get some people are upset, some people are against this, but this is simply not going to change.

It gives us velocity during development, it defines our preferences, it ensures Discourse as used by the vast majority of people is more stable.

@RGJ

But adding those plugins in a default production install kind of defeats the idea of having a plugin

There are other plugins… core plugins are not the only plugins.

[Thomas_Rother (Thommie Rother)]

I absolutely agree that it makes sense to move popular plugins and their functionality into the core image. Especially if they come from the same coders (CDCK) as the core itself. This is common practice even for other software projects. But we should solve the bootstraping issues - I am still optimistic

[merefield (Robert)]

Het is de reden dat je niet kunt herbouwen.

[Heliosurge (Dan DeMontmorency)]

@RGJ

@david

The motivation here is to to provide a smoother experience for first-time users of Discourse, so that they get a more “fully featured” Discourse experience right out-the-box.

That could have also been resolved in the setup script by showing a list of plugins that users can check and then adding them to app.yml

This definitely would be the better path. It can still be implemented with using the remove plugin code in the previous post.

Adding that to the install script gives a much better options out of the box and is quite common in programs to let you choose whether or not to install certain optional features.

Comparability file is cool. Though Imho a comparability info should be added to topics. With link or instructions for if the TC/plugin is available for both Stable and Tests-passed install instructions.

[RoldanLT]

@SkyeDragon

but it does work. Example:

## Plugins go here
## see https://meta.discourse.org/t/19157 for details
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/pfaffman/discourse-allow-pm-to-staff.git
          #- git clone https://github.com/discourse/discourse-hcaptcha.git
          #- git clone https://github.com/discourse/discourse-calendar.git
          - rm -rf discourse-adplugin
          - rm -rf discourse-affiliate
          - rm -rf discourse-ai
          - rm -rf discourse-apple-auth
          - rm -rf discourse-assign
          - rm -rf discourse-login-with-amazon
          - rm -rf discourse-lti
          - rm -rf discourse-microsoft-auth
          - rm -rf discourse-patreon
          - rm -rf discourse-subscriptions
          - rm -rf discourse-zendesk-plugin

(Tune as desired)

Thanks for the guide; this works great except for the “automation” plugin, which can’t be removed, as it seems the chat plugin depends on it.

[Heliosurge (Dan DeMontmorency)]

De automatiseringsplugin is iets dat echt niet verwijderd zou moeten worden, eerlijk gezegd. Het heeft zoveel nuttige potentiële toepassingen. Er moet meer tijd in geïnvesteerd worden naar mijn mening om meer automatiseringsopties te krijgen.

Maar ja, het is cool dat er een optie is om op te ruimen door add-ons te verwijderen die, zoals @RGJ heeft aangegeven, de echte extra’s recentelijk enigszins samengevoegd zijn, waardoor de vraag kan worden gesteld of deze opties gewenst zijn om te installeren. Misschien zelfs een apart script voor na de installatie om dingen vriendelijker te maken voor self-hosted, zodat sommigen die het bewerken van de app.yml willen vermijden.