Bündelung beliebterer Plugins mit Discourse Core

Ankündigungen
80

Nachdem ich früh in meinem Discourse-Self-Hosting vom Problem „Plugin-Fehler beim Wiederaufbau“ betroffen war, kann ich den Wunsch verstehen, bekannte gute Versionen in den Kern zu bündeln. Und potenziell eine größere Auswahl an Funktionen anzubieten.

Eine kundenorientierte Organisation hätte eine Umfrage zur Kern-Plugin-Ausrichtung oder zumindest zum Timing durchführen können. Vielleicht habe ich das verpasst. Als IT-Toolanbieter für meine Kunden (d. h. Endbenutzer), die mit der IT reale Arbeit erledigen wollen, habe ich viele Produkte gesehen, die zu übermäßiger Komplexität überarbeitet und schließlich ersetzt wurden. Jetzt werden Self-Hosters Plugins, die sie nicht benötigen, „rm -fr“en. Das verstehe ich und schließe mich vielleicht diesem Club an. Meiner Erfahrung nach erhöht zusätzlicher Code die Integrationskomplexität, das Risiko von Konfigurationsfehlern und die Angriffsfläche. Aber früher oder später wird das Entfernen von etwas, von dem der Anwendungsentwickler annimmt, dass es vorhanden sein wird, auch etwas kaputt machen.

Ich hätte es viel besser gefunden, wenn die Bemühungen der Discourse-Jedi darauf verwendet worden wären, eine robuste, gepflegte und geskriptete Methode für die Cloud-Speicherung von Bildern einschließlich CDN-Integration zu entwickeln. Die SMTP-E-Mail-Integration ist im Vergleich trivial, und diese ist mit Änderungen bei MailGun und anderen gebrochen, was Self-Hosted-Sites Kummer bereitet.

81

In der Tat würde ich dringend davon abraten, diese Plugins mit rm -rf zu entfernen. Wie Sie sagen, gibt es Risiken hinsichtlich unerwarteter Abhängigkeiten in der Zukunft. Aber Sie werden auch einen Unterschied im Kern-Git-Repository erstellen, was bedeutet, dass UI-Updates über docker_manager mit ziemlicher Sicherheit fehlschlagen werden.

Natürlich ist es völlig unterstützt, diese Plugins in ihrem standardmäßigen „deaktivierten“ Zustand zu belassen, und sie werden keine messbaren Auswirkungen auf die Leistung haben.

8 „Gefällt mir“
82

Wir brauchen eine Möglichkeit, Plugins vom Auffinden auszuschließen, auch wenn sie sich im Plugins-Verzeichnis befinden.

2 „Gefällt mir“
83

Für Self-Hosters oder diejenigen, die wie ich Hosting-Dienste für Kunden anbieten, hier ist ein einfaches grep, das auflistet, ob eines der neuen gebündelten Plugins bereits in Ihrer containers/app.yml vorhanden ist.

grep -E 'git clone .*(discourse-(adplugin|affiliate|ai|apple-auth|assign|calendar|chat-integration|data-explorer|gamification|github|graphviz|hcaptcha|login-with-amazon|lti|math|microsoft-auth|oauth2-basic|openid-connect|patreon|policy|post-voting|reactions|rss-polling|solved|subscriptions|templates|topic-voting|user-notes|zendesk-plugin|cakeday))' containers/app.yml

Muss als root ausgeführt werden und gibt alle Zeilen aus, die manuell aus dem Plugin-Abschnitt der app.yml entfernt werden müssen, bevor Sie neu erstellen.

9 „Gefällt mir“
84

@pacharanero Danke, dass du das zusammengestellt hast!

Vielleicht könntest du es so ändern, dass es sich auf containers.*.yml bezieht, damit es auch jedem hilft, der eine Standard-Zwei-Container-Installation durchgeführt hat, bei der sie stattdessen im Web-Only-Bereich wären? Du willst sie schließlich nicht in deinen Container-Definitionen haben. :smiling_face:

@david Würdest du das in den ersten Beitrag aufnehmen und es pflegen, sobald du cakeday integriert hast?

2 „Gefällt mir“
85

Dank an ChatGPT, das es mit diesem Prompt auf Anhieb genau richtig erstellt hat:

Bitte extrahiere die GitHub-URLs aller Plugins, die in diesem Beitrag erwähnt werden
https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574#p-1810533-affected-plugins-3

Stelle sie in einer Liste zusammen und erstelle einen Unix-Befehl, der mir sagt, ob eines dieser Plugins bereits in einem ‘git clone’ in der Discourse-Datei containers/app.yml erwähnt wird.

3 „Gefällt mir“
86

[quote=„elmuerte, Beitrag:82, Thema:373574″]
Wir brauchen eine Möglichkeit, Plugins vom Auffinden auszuschließen, auch wenn sie sich im Plugins-Verzeichnis befinden.

[/quote]

Oberflächlich betrachtet klingt das für mich nach einer vernünftigen Sache, die man irgendwann in Betracht ziehen könnte – eine deklaretere Möglichkeit zu haben, zu definieren, welche Plugins beim Booten geladen werden oder nicht, auch wenn die Quelle noch auf der Festplatte vorhanden ist.

Davon abgesehen weiß ich nicht, wie machbar oder aufwendig das wäre.

3 „Gefällt mir“
87

Es ist durchaus möglich. Aber es erhöht die Komplexität – eine weitere Sache, die unterstützt/gewartet werden muss. Und es wäre nur in Single-Tenant-Umgebungen nützlich (d. h. nicht in Shared-Hosting-Umgebungen, in denen verschiedene Mandanten unterschiedliche Plugins wünschen).

Wenn überhaupt, denke ich, wäre es vorteilhafter, Zeit in die Verbesserung der Benutzererfahrung und Leistung von ‘deaktivierten’ Plugins zu investieren (was wir bereits tun, seit dieser große Merge in den Core stattgefunden hat).

10 „Gefällt mir“
88

Außerdem habe ich nicht versucht, die Plugins zu entfernen, da ich befürchte, dass dies meine Fehlerberichte an das Meta beeinträchtigen würde, ebenso wie der Versuch einer Shared Hosting-Installation.

2 „Gefällt mir“
89

Uff, das war ein holpriges Update. Das Problem im Durcheinander des Rebuild-Logs zu identifizieren, ist von Anfang an nicht gerade trivial. Gefunden, habe ein weiteres Plugin übersehen, das aus unserer Konfiguration entfernt werden muss, zweimal, daher hat der 3. Rebuild-Versuch diesen Teil endlich bestanden. Es wäre wirklich hilfreich gewesen, wenn gleich zu Beginn geprüft und gewarnt worden wäre, dass die Konfiguration angepasst werden muss. discourse-doctor prüft (zu einfach, aber kann als Anfang genommen werden) auf Plugins in der Konfiguration, daher kann das als Basis verwendet werden. Wahrscheinlich zu spät jetzt 3 Wochen später, egal …

Aber das war noch nicht alles, wir sind auch in db:migrate-Fehler gelaufen. Habe es 2 Mal erneut versucht, dann discourse-doctor ausgeführt, was auch den Rebuild ausgeführt hat und seltsamerweise erfolgreich war. Ich habe mir den Code angesehen, und er tut absolut nichts und ruft den Rebuild genauso auf, wie wir es tun. Daher sieht es so aus, als ob db:migrate aus irgendeinem Grund beim 3. Versuch erfolgreich war? Ich habe den Thread durchgelesen, dass die große Anzahl von hinzugefügten Plugins Abhängigkeiten hinzufügt, die möglicherweise mit dem, was zuvor verwendet wurde, in Konflikt stehen/älter sind. Glücklicherweise mussten wir keinen manuellen Schritt zur Plugin-Entfernung, zur Anpassung von Abhängigkeiten oder zur Datenbankänderung hinzufügen, wie es andere anscheinend benötigt haben. Ist es irgendwie zu erwarten, dass das mehrmalige Ausführen von db:migrate schließlich erfolgreich sein wird? Ich kann nur hoffen, dass nichts kaputt ist …

2 „Gefällt mir“
90

Es wurde früher installiert, wir haben es nur zusammen mit den anderen gebündelten Plugins von früher aus der Benutzeroberfläche weggelassen. Unsere Benutzeroberfläche wurde verbessert, um alles, was existiert, richtig anzuzeigen. (Wir hatten eine Reihe von Auslassungen, einschließlich Chat, der per CSS ausgeblendet wurde)

Ich habe bereits eine Zunahme der Geschwindigkeit des internen Entwicklungsteams in der sehr kurzen Zeit, seit dies in Kraft ist, beobachtet. Es führt zu einem stabileren Produkt, worüber ich sehr glücklich bin.

Es gibt keine Pläne, hier zurückzurudern. Sie müssen sich an die neue Welt anpassen.

4 „Gefällt mir“
91

3 Beiträge wurden in ein neues Thema aufgeteilt: Hilfe beim Debuggen fehlgeschlagener Migrationen

93

Meiner Meinung nach ist es ein Fehler, wenn etwas kaputt geht, weil ein Plugin nicht installiert ist. Die Kernsoftware sollte nicht von Plugins abhängen. Plugins selbst sollten ihre Anforderungen auf ihren jeweiligen Seiten klar auflisten.

Aber ja, dies wird die selbst gehostete Version in Zukunft noch instabiler machen, da die Selbsthoster mit diesen Problemen zu kämpfen haben werden. Zwischen diesem und dem abgespaltenen Thread habe ich wirklich nicht den Eindruck, dass die Stabilität von Selbsthostern für das Team eine hohe Priorität hat.

2 „Gefällt mir“
94

Das hatten wir im Vorfeld nicht bedacht, daher könnten einige Freigaben fehlen. Aber wir haben es geschafft, einen guten Teil davon von den Plugin-Projekten auf Crowdin in den Core zu übertragen. Beim nächsten Mal machen wir es besser, da wir jetzt die Werkzeuge haben, um Freigaben zwischen Projekten zu übertragen.

image
image1161×1236 202 KB

Nein, das haben wir vorher nicht geprüft, aber ich habe es danach geprüft. Keiner der Plugins hatte unbeantwortete Kommentare auf Crowdin. Wir haben ein internes Werkzeug, das alle Kommentare speichert, die auf unseren Crowdin-Plugins gepostet werden. Wir könnten es sogar verwenden, um fehlende Kommentare wieder auf Crowdin zu posten, z. B. wenn Crowdin Kommentare löscht, weil die Quellzeichenfolge aktualisiert wurde. Es war einfach keine Priorität, dies zu implementieren.

6 „Gefällt mir“
96

Es wäre wirklich schön, hier noch eine weitere Option zu haben:

image
image406×223 4.8 KB

„Aktivierte Plugins“

Dies würde die anfänglich riesige Liste unter „Installierte Plugins“ vermeiden.

Außerdem, um dies zu erleichtern:

  • Benutzerdefinierte Links im Abschnitt „Plugins“ zulassen (vielleicht)
  • Dieses Dropdown-Menü auf einen Routenparameterfilter reagieren lassen:

image
image396×179 1.17 KB

also:

https://example.com/admin/plugins?filter=enabled

12 „Gefällt mir“
98

Einverstanden. Vielleicht eine Option, aktivierte Kern-Plugins aufzulisten. Im Gegensatz zu „Alle Plugins anzeigen“. Zusätzliche Filteroptionen sind definitiv besser.

1 „Gefällt mir“
99

Ich stimme der Meinung zu. Meiner Meinung nach liegt die wirkliche Trennung darin, sie weiterhin als Plugins aufzuführen.

Sobald sie zusammengeführt sind, sollten sie in etwas umbenannt werden wie „Kernfunktionen“, da Plugins als optionale Komponenten angesehen werden, die installiert werden können. Im Gegensatz zu einem Teil des Hauptprogramms. Es ist also meiner Meinung nach ein falscher Begriff, sie weiterhin als Plugins aufzuführen, wenn die Absicht nicht ist, sie zu deinstallieren.

Ähnlich wie TC, die in den Kern integriert wurden, wie „persönliche Blasen“, wird nicht in Theme Components aufgeführt. Zugegebenermaßen kann man in diesem speziellen Fall die ehemaligen TC nicht deaktivieren. Wenn Sie zu dem zurückkehren wollten, was es vorher war, mussten Sie eine TC erstellen, um die Änderungen rückgängig zu machen, :wink:

100

[quote=„merefield, post:96, topic:373574"]
Aktivierte Plugins”

Dies würde die anfängliche massive Liste unter Installierte Plugins vermeiden.
[/quote]

Ich stimme auf jeden Fall zusätzlichen Filteroptionen zu. Eine für deaktivierte Plugins wäre auch gut.

Nach weiterem Nachdenken und Lesen weiterer Beiträge: Wenn die Plugins mit dem Kern zusammengeführt werden, sollten sie wirklich nicht mehr Plugins genannt werden und nicht unter Plugins aufgeführt werden. Sondern vielleicht etwas wie Kernfunktionen oder Optionale Funktionen. Da diese nicht mehr wirklich deinstalliert werden können.

1 „Gefällt mir“
101

[quote=„Heliosurge, Beitrag:99, Thema:373574″]
Sobald es zusammengeführt ist, sollte es in etwas Markenbezogenes wie „Kernfunktionen“ verschoben werden, da Plugins als optionale Komponenten angesehen werden, die installiert werden können. Im Gegensatz zu einem Teil des Hauptprogramms. Daher ist es meiner Meinung nach irreführend, sie weiterhin als Plugins aufzulisten, wenn die Absicht nicht ist, sie zu deinstallieren.

[/quote]

Es gibt keinen Grund, warum ordnungsgemäß entwickelte Forensoftware Werbecodes zum Ausführen benötigt sollte.

Wenn Discourse beschließt, Anti-Features einzubauen, wird es die Leute nur dazu zwingen, Discourse zu forken oder zu etwas anderem zu migrieren. Diejenigen von uns, die Big Tech / Werbekram nicht mögen, sind sehr entschlossen, was das angeht. Discourse wird es uns NICHT aufzwingen, egal wie sehr es gedrängt wird. (Ubuntu hat das bei uns versucht und jetzt ist mein am höchsten bewertetes Repository etwas, das die Werbung entfernt ;))

102

Ich bin mir nicht sicher, ob ich folgen kann. Wenn Sie mit Werbecode Plugins meinen, die in das Kernprodukt integriert sind, im Gegensatz zu optionalen Add-ons/Installationen. Wenn wir zurückgehen, werden Sie feststellen, dass eine Vielzahl von “Werbecodes” in den Kern integriert wurde.

Ich kann aus der Perspektive des DeV-Teams sehen, dass viele ihrer Plugins als Plugins begonnen haben, um flexiblere Tests zu ermöglichen, bevor sie in das Kernprogramm integriert wurden.

Ich kann, wie bei jeder Software, verstehen, dass es oft Funktionen gibt, die die Leute vielleicht nicht nutzen und deaktivieren möchten, und dass es darum geht, Wege zu finden, Funktionen zu deinstallieren.

Obwohl ich zugebe, dass es viele neue integrierte Plugins gibt, die ich wahrscheinlich nicht verwenden würde. Aber ein einfaches Deaktivieren und Herausfiltern ist für alle gut.

Ich verstehe, dass die Absicht des Teams teilweise darin besteht, die Dinge mit Add-ons für Self-Hosted zu vereinfachen.

Meiner Meinung nach sollte die Admin-Oberfläche anpassbarer sein, wie sie es einmal war. Dies kann auch Menschen helfen, die von einer anderen Plattform migrieren, indem sie eine Admin-Oberfläche laden können, die dem Layout der Plattform ähnelt, von der sie kommen. Ähnlich wie Linux dies mit einigen Nachahmungen anderer Betriebssysteme tut. Aber das ist ein anderes Thema. :wink:

Ich kann das Gefühl nachvollziehen, dass Discourse langsam in Richtung Bloatware tendiert. Reaktoren haben gezeigt, wie viel schlanker Windows NT sein könnte.