אריזת תוספים פופולריים יותר עם ליבת Discourse

[Stephen]

אם השגיאה אומרת ש-reactions, data explorer ו-solved עדיין קיימים בקובץ ה-yml שלך, אז סביר להניח שהם שם. אם אתה חושב שהערת אותם, האם ייתכן שהם הוכנסו פעמיים?

בהחלט כדאי לבדוק את התצורה ולוודא שערכת את קובץ ה-yml המתאים לאתר שלך.

[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]

הממ… האם ייתכן שזה בגלל שאתה על גרסה יציבה?

[evenlo]

בעקבות הנחיית המערכת, הסרתי את התוסף discourse-oauth2-basic לפני שהצלחתי לשדרג לגרסת היציבה 3.4.6.

עם זאת, גיליתי כעת שאפשרויות התצורה עבור OAuth 2 Basic חסרות מלוח המחוונים של המנהל.

[david (David Taylor)]

אם אתה משתמש בגרסה היציבה (stable), אז אף אחד מהנושאים האלה לא יחול עד לאחר השחרור היציב הבא בתחילת אוגוסט. לכן, עליך להוסיף את oauth2-basic בחזרה לקובץ app.yml שלך. הכשל המקורי חייב היה להיות מסיבה אחרת כלשהי.

למרבה הצער, הלוגיקה של ‘hint’ אינה חכמה במיוחד, והיא אינה מודעת להבדל בין גרסה יציבה לבין גרסת 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 תראה את זה, התרגום של הציטוט שלי והתשובה שלי

[bayardo.rivas]

לא משנה איך ניסיתי להגיב על שורות השיבוט בחלק התוספים, אבל זה קרא את השורות האלה כאילו רציתי להתקין את התוספים. מה עשיתי? הסרתי את השורה ולבסוף עבד.

כאשר אתה משדרג, עליך לבדוק את רשימת התוספים הכלולים בליבה של Discourse כדי לא להוסיף אותם בחלק התוספים להתקנה או להסיר את השורה אם יש לך אותה בקובץ app.yml שלך.

[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)]

העדפתי גם את הגישה של ביטול ההערה בקובץ app.yml.

[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)]

זו הסיבה שאינך יכול לבנות מחדש.

[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)]

תוסף האוטומציה הוא משהו שלא באמת צריך להסיר, בכנות. יש לו כל כך הרבה שימושים פוטנציאליים שימושיים. הוא זקוק להשקעת זמן נוספת לדעתי כדי לקבל עוד אפשרויות אוטומציה.

אבל כן, זה מגניב שיש אפשרות לנקות על ידי הסרת תוספות, כפי שציין @RGJ, שהאקסטרות האמיתיות שמוזגו לאחרונה ניתן לשאול אם האפשרויות הללו רצויות להתקנה. אולי אפילו סקריפט נפרד לאחר ההתקנה רק כדי להפוך דברים לידידותיים יותר עבור אירוח עצמי, כך שאלו שרוצים להימנע מעריכת ה-app.yml.