Wenn der Fehler besagt, dass reactions, data explorer und solved sich noch in Ihrer YML-Datei befinden, dann sind sie das wahrscheinlich auch. Wenn Sie glauben, sie auskommentiert zu haben, könnten sie dann doppelt eingegeben worden sein?
Es lohnt sich auf jeden Fall, die Konfiguration zu überprüfen und sicherzustellen, dass Sie die YML-Datei bearbeitet haben, die Ihrer Website entspricht.
Hallo
Ich habe mein Forum erfolgreich auf die neueste 3.4.6 stabile Version aktualisiert. Zuvor habe ich das eigenständige Plugin discourse-oauth2-basic zur Authentifizierung verwendet.
Es gibt keine Oauth2 Basic-Anmeldung unter /admin/plugins.
Meine Discourse-Version ist 3.4.6.
HINWEIS: Das Plugin ‘discourse-oauth2-basic’ ist jetzt in Discourse integriert und sollte nicht in Ihrer Container-Konfiguration enthalten sein.
Entfernen Sie die Zeile ‘git clone GitHub - discourse/discourse-oauth2-basic: A basic OAuth2 plugin for use with Discourse’ aus Ihrer Datei containers/app.yml und versuchen Sie es erneut.
Weitere Informationen finden Sie unter Bundling more popular plugins with Discourse core
Ich musste das Plugin discourse-oauth2-basic vor dem Upgrade auf 3.4.6 entfernen.
Können Sie mir bitte helfen zu verstehen, was schiefgelaufen sein könnte?
Vielen Dank!
Hmm… könnte es daran liegen, dass du auf stabil bist?
Nachdem ich dem System-Prompt gefolgt war, habe ich das Plugin discourse-oauth2-basic entfernt, bevor ich erfolgreich auf die stabile Version 3.4.6 aktualisiert habe.
Ich habe jedoch jetzt festgestellt, dass die Konfigurationsoptionen für OAuth 2 Basic im Admin-Dashboard fehlen.
Wenn Sie sich auf Stable befinden, dann trifft keines dieser Themen zu, bis nach der nächsten Stable-Version Anfang August. Sie sollten also oauth2-basic wieder zu Ihrer app.yml hinzufügen. Das ursprüngliche Problem muss aus einem anderen Grund aufgetreten sein.
Leider ist die ‘Hint’-Logik nicht sehr intelligent und kennt weder Stable noch Tests bestanden.
Ich auch, aber was können wir dagegen tun? lol Ich denke, dass mehr native Ressourcen, auch bekannt als Plugins, selbst wenn sie deaktiviert sind, keine gute Lösung sind, um Anfängern beim Selbsthosten zu helfen.
@nat Schau dir das an, meine Zitatübersetzung und meine Antwort
Egal wie ich versucht habe, die Klonzeilen im Plugin-Bereich auszukommentieren, wurde diese Zeilen als Installationswunsch für die Plugins gelesen. Was habe ich getan? Die Zeile entfernt und schließlich hat es funktioniert.
Wenn Sie ein Upgrade durchführen, müssen Sie die Liste der Plugins überprüfen, die im Kern von Discourse enthalten sind, um sie nicht im Plugin-Bereich zur Installation hinzuzufügen oder diese Zeile zu entfernen, wenn Sie sie in Ihrer app.yml-Datei haben.
Ich denke, da diese vorinstalliert sind. Es sollte Optionen geben, die diese 
von der installierten Liste trennen. Da die installierte Liste deinstallierbar ist, im Gegensatz zu nur deaktivierbar.
Vielleicht sollten für Kern-Plugins, die zusammengeführt wurden, etwas wie „Empfohlene Plugins“ oder „Kern-Plugins“ darunter aufgeführt werden.
Mit natürlich vielleicht einem „Alle“-Filter.
Ihr Vorschlag ist nicht ideal, aber er funktioniert. Beispiel:
## Plugins kommen hierher
## siehe https://meta.discourse.org/t/19157 für 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
(Nach Belieben anpassen)
7 Beiträge wurden in ein neues Thema aufgeteilt: Fehlerbehebung bei Bootstrap-Fehlern in Discourse
Die Realität ist, dass die stabile Version ein LTS ist, und zwar ein ziemlich gutes. Sie erhält Sicherheitsupdates und es ist ziemlich klar, welche Plugin-Versionen damit kompatibel sind (dank der .discourse-compatibility-Datei). Ich gebe zu, dass es lange gedauert hat, bis das alles funktionierte, aber in den letzten etwa zwei Jahren hat es funktioniert – was eine großartige Leistung des Teams ist.
Nun zum zweiten Teil Ihrer Aussage. Es ist tatsächlich so, dass stable oft als etwas dargestellt wird, das man nicht haben möchte. Aber bei Communiteq Hosting bieten wir seit 2,5 Jahren Kunden die freie Wahl zwischen Stable („Stabilität zuerst, neue Updates zweimal im Jahr, Sicherheitsupdates einmal im Monat“) und Tests-bestanden („immer am Puls der Zeit, neue Funktionen einmal im Monat“) und 85 % entscheiden sich für Stable.
Das verstehe ich. Aber ist das nicht ein Entwicklungsproblem und kein Produktionsproblem? Ich kann durchaus verstehen, dass Sie das in der Entwicklung tun. Aber diese Plugins in eine Standard-Produktionsinstallation aufzunehmen, untergräbt die Idee, ein Plugin zu haben (das per Definition etwas Nicht-Standardmäßiges ist).
Die einzige tatsächliche Produktionsvorteil, den ich sehe, ist das sehr, sehr Randproblem des Deinstallierens von Plugins und Multisite-Hosts. (Auch hier ist das eine gute Sache, alle anderen Produktionsprobleme wurden im Laufe der Zeit gelöst!)
Das hätte auch im Setup-Skript gelöst werden können, indem eine Liste von Plugins angezeigt wird, die Benutzer auswählen können, und diese dann zu app.yml hinzugefügt werden.
Aber Sie bieten immer noch unterschiedliche (Teil-)Sets von Plugins für verschiedene Stufen an, richtig?
Ich hätte den Ansatz mit der auskommentierten app.yml ebenfalls bevorzugt.
Alle diese Plugins sind auf allen unseren Self-Service-Plänen installiert. Einige Stufen haben keinen Zugriff, aber sie bleiben installiert, auch wenn sie keinen Zugriff haben.
Wir werden diese Entscheidung nicht ändern, daher müssen die Leute einfach damit leben. Ich verstehe, dass einige Leute verärgert sind, einige Leute dagegen sind, aber das wird sich einfach nicht ändern.
Es gibt uns Geschwindigkeit während der Entwicklung, es definiert unsere Präferenzen, es stellt sicher, dass Discourse, wie es von der überwiegenden Mehrheit der Menschen genutzt wird, stabiler ist.
Es gibt andere Plugins… Kern-Plugins sind nicht die einzigen Plugins.
Ein Beitrag wurde in ein neues Thema aufgeteilt: Discourse liefert keine LTS-Version aus
Ich stimme vollkommen zu, dass es sinnvoll ist, beliebte Plugins und deren Funktionalität in das Kern-Image zu verschieben. Besonders wenn sie von denselben Programmierern (CDCK) wie der Kern selbst stammen. Dies ist auch bei anderen Softwareprojekten üblich. Aber wir sollten die Bootstrapping-Probleme lösen - ich bin immer noch optimistisch 
Das ist der Grund, warum Sie nicht wieder aufbauen können.
Das wäre definitiv der bessere Weg. Es kann immer noch mit dem Code zum Entfernen von Plugins aus dem vorherigen Beitrag implementiert werden.
Das Hinzufügen zu diesem Installationsskript bietet von Anfang an viel bessere Optionen und ist bei Programmen recht üblich, Ihnen die Wahl zu lassen, ob Sie bestimmte optionale Funktionen installieren möchten oder nicht.
Die Vergleichbarkeitsdatei ist cool. Obwohl meiner Meinung nach Vergleichbarkeitsinformationen zu Themen hinzugefügt werden sollten. Mit einem Link oder Anweisungen, falls der TC/das Plugin sowohl für Stable als auch für Tests-bestanden Installationsanweisungen verfügbar ist.
Danke für die Anleitung; das funktioniert hervorragend, außer dem „automation“-Plugin, das nicht entfernt werden kann, da das Chat-Plugin davon abzuhängen scheint.
Das Automatisierungs-Plugin sollte meiner Meinung nach wirklich nicht entfernt werden. Es hat so viele nützliche potenzielle Anwendungen. Es braucht mehr Zeit, um mehr Automatisierungsoptionen zu erhalten.
Aber ja, es ist cool, dass es eine Option gibt, aufzuräumen, indem Add-ons entfernt werden, die, wie @RGJ angemerkt hat, die wirklich zusätzlichen Funktionen, die kürzlich zusammengeführt wurden, ob diese Optionen gewünscht sind zu installieren. Vielleicht sogar ein separates Skript für nach der Installation, um es für Self-Hosted benutzerfreundlicher zu machen, damit einige, die die Bearbeitung der app.yml vermeiden möchten.