In den nächsten Wochen werden wir eine Reihe beliebter Discourse-Plugins in das Kernrepository verschieben. Das bedeutet, dass Discourse standardmäßig eine größere Anzahl von Plugins enthalten wird und es für uns einfacher sein wird, sie alle getestet und auf dem neuesten Stand zu halten.
Alle diese Plugins bleiben standardmäßig deaktiviert, sodass dies keine sichtbaren Auswirkungen auf bestehende Communities hat. Wenn Sie einen verwalteten Hosting-Service wie discourse.org nutzen, müssen Sie nichts weiter tun.
Selbst gehostete Communities
Wenn Sie Discourse selbst hosten und bereits eines dieser Plugins verwenden, werden Sie aufgefordert, die entsprechende Zeile aus Ihrer app.yml-Datei zu entfernen, bevor Sie das nächste Mal neu erstellen.
Entwicklungsumgebung
Wenn Sie eines der Plugins bereits lokal installiert haben und dann die neueste Version von Discourse Core herunterladen, tritt eines von zwei Dingen ein.
Wenn Sie Symlinks für Ihre Plugins verwenden, erhalten Sie beim Ausführen von git pull einen Fehler. Um das Problem zu beheben, löschen Sie den Symlink und führen Sie dann erneut git pull aus.
Wenn Sie Plugins direkt klonen, wird der git pull des Kerns erfolgreich sein, aber Sie werden einige überraschende “unbestätigte Änderungen” aufgrund der verschachtelten Git-Repositories haben. Der beste Weg, um fortzufahren, ist, das betroffene Verzeichnis zu löschen und es dann von main wiederherzustellen. Zum Beispiel:
Danke für die Bereitstellung der vollständigen HINT-Zeile im ersten Beitrag hier, das hat mir heute Morgen geholfen, einen fehlgeschlagenen Wiederaufbau zu diagnostizieren
Danke. Mit meinem geringen Wissen über Entwicklung und Programmierung möchte ich Ihnen dennoch eine Frage stellen. Können diese Plugins, die ursprünglich als Komponenten für eine Basisinstallation gedacht waren, eines Tages ihren Plugin-Charakter verlieren und ein vollständiger Teil einer Basisinstallation werden, ohne überhaupt als Plugins bezeichnet zu werden?
Das könnten sie, ja. Insbesondere die Authentifizierungs-Plugins (z. B. apple-auth) werden wahrscheinlich in den Kern integriert, genau wie unsere anderen integrierten Authentifizierungsmethoden (z. B. Google, Facebook usw.).
Wenn ich mich richtig erinnere, können Sie zunächst nur Docker aktualisieren. Sobald Sie Docker aktualisiert haben, wird Ihnen in der Update-Benutzeroberfläche eine Meldung angezeigt, die erklärt, dass Sie über die Befehlszeile aktualisieren müssen und wie Sie dies tun können.
Wenn Sie dann über die Befehlszeile aktualisieren, sehen Sie den HINWEIS für jedes Plugin, das Sie aus app.yml entfernen müssen, wie im ersten Beitrag oben erklärt.
Dies ist ein gutes Update, aber war das wirklich notwendig? Einen Wiederaufbausfehler zu melden, erscheint mir etwas hart… eine UI-Warnung oder ein automatisches Update (oder sie einfach komplett zu ignorieren) wäre netter gewesen, als mir eine Pistole an den Kopf zu halten und zu sagen: “Entferne diese jetzt”.
Das ist mir letzte Woche passiert, als ich versucht habe, über die Befehlszeile zu aktualisieren, und es fehlgeschlagen ist (Reaktions-Plugin).
Es ist mir heute Morgen wieder passiert, als mein Befehlszeilen-Update erneut fehlgeschlagen ist (Daten-Explorer-Plugin).
Ich würde mich sehr über eine Warnung in der Befehlszeile freuen, bevor der Update-Prozess beginnt und dann zwangsläufig fehlschlägt.
Jetzt schon zweimal in zwei Wochen sind meine Updates fehlgeschlagen, und das bedeutete, dass mein Discourse für die Dauer der Fehlersuche, Konfigurationsänderungen, erneuten Versuche usw. offline war – und das alles in einem leichten Panikzustand, weil alles kaputt ist.
Ich bin neugierig, hast du diese Liste von Plugins aus Discourse-Installationen in freier Wildbahn erhalten? Sie stimmt fast mit 50 % meiner eigenen Hauptinstallation überein!
Ich frage mich, ob das Bündeln all dieser Plugins im Kern die Foren aufblähen würde? Da es wahrscheinlich ein paar Plugins geben wird, die Administratoren nicht auf ihrem Forum haben wollen (z. B. Discourse AI), aber keine andere Wahl haben, als sie hinzuzufügen. Sie können natürlich deaktiviert werden, aber ich frage mich, ob die zusätzlichen Dateien und so weiter die Foren verlangsamen werden?
Auf der Clientseite liefert Discourse keine JavaScript-Assets für deaktivierte Plugins aus, sodass es dort keine Auswirkungen gibt.
Auf der Serverseite werden bei ordnungsgemäß implementierten Plugins (was bei allen hier der Fall ist) Anpassungen von Plugins umgangen, wenn sie deaktiviert sind. Technisch gesehen mag es also einen geringen Mehraufwand für die Überprüfung des Aktivierungs-/Deaktivierungsstatus geben, aber dieser sollte minimal sein.
Zum Kontext: Die hier zusammengeführten Plugins sind diejenigen, die wir auf jeder einzelnen Instanz von Discourse auf unserem discourse.org-Hosting ausführen. Sie sind also alle im großen Maßstab sehr gut getestet.
Gibt es einen Grund, warum Sie all dies kurz vor der Veröffentlichung auf einmal tun? Für Übersetzer, die dies in ihrer Freizeit tun, sind 3.000 zusätzliche Zeichenketten innerhalb von zwei Wochen viel. Und selbst in Sprachen, in denen die Plugins zuvor übersetzt wurden, müssen alle 3.000 Texte erneut Korrektur gelesen werden. Ab und zu wären 300 wahrscheinlich besser zu bewältigen als 3.000.
Werden für selbst gehostete Communities, auf denen bereits eines oder mehrere dieser Plugins ausgeführt werden, die Konfigurationsdaten verloren gehen, wenn sie aus der app.yml entfernt und in den Kern integriert werden?
Ich habe das KI-Plugin genau so eingerichtet, wie ich es möchte. Wenn ich es neu konfigurieren muss (oder zumindest die Konfigurationsoptionen aufschreiben muss, damit ich sie wieder hinzufügen kann), wäre es gut zu wissen.
Wir haben versucht, dies für die Übersetzer so reibungslos wie möglich zu gestalten, indem wir den Translation Memory in Crowdin nutzen, damit Übersetzungen nicht von Grund auf neu erstellt werden müssen. Aber trotzdem stimme ich zu, es gibt viel zu Korrekturlesen.
Ich frage mich, ob wir hier mehr automatisieren können, z. B. ob wir alle Strings aus diesen Plugins „automatisch genehmigen“ können, anstatt eine Korrektur zu verlangen
Die gesamte Konfiguration/die gesamten Daten werden beibehalten.
Dieses Meta-Thema ist nicht wirklich das, was Sie sehen möchten.\n\nDie Schwierigkeit liegt darin zu wissen, welche Plugins Sie aus Ihrer app.yml entfernen sollten und welche nicht.
