Ich glaube, was sie vorschlagen, ist, dass, wenn ein Plugin, das bereits mit dem Kern gebündelt war, in app.yaml aufgeführt wäre, es einfach ignoriert würde. Mit einer Benachrichtigung, dass die Aufnahme in app.yaml redundant war und der Eigentümer sie entfernen könnte.
Auch ich finde es ein wenig ärgerlich, dass ich, solange ich Plugins in meiner app.yaml aufgeführt habe, immer das Risiko eines fehlgeschlagenen Updates eingehe. Jedes Mal, wenn ich das Update durchführe, muss ich also überprüfen, ob eines meiner Plugins in den Kern aufgenommen wurde.
Warum nicht einfach ein Skript, das das für den Sysop erledigt?
Ich selbst organisiere Plugins nach Team oder Autor, um mir das Leben ein wenig zu erleichtern, damit ich weiß, welche Plugins offiziell sind und so weiter. Aber wenn die Idee ist, Discourse benutzerfreundlicher zu machen, muss das auf Teamebene geschehen.
Nicht wirklich anders, wenn Sie Leute beraten haben, als ein Benutzer ein fehlerhaftes Upgrade aufgrund eines Postreq (so?) Upgrade-Fehlers hat.
Bei Plugins ist genau hier das Konzept des Procourse Installers eine großartige Idee, um die Installation und Deinstallation von Plugins zu vereinfachen, ohne die Befehlszeile verwenden zu müssen.
Zugegeben, ich verstehe, dass es vielleicht noch etwas mehr Schliff brauchte, falls etwas schiefging. Aber das könnte mit einer Log-Datei oder einem einfachen Fallback von der Befehlszeile aus leicht genug gemacht werden. Ich schätze es, dass dies es für Self-Hosting attraktiver machen könnte als ein kostenpflichtiger Plan. Es gibt jedoch genügend Vorteile für einen kostenpflichtigen Plan, um diesen immer noch zu wählen.
Diese Art von Plugin-Manager könnte auch erstellt oder verzweigt werden, um gehosteten Plänen die Installation von Plugins innerhalb ihrer gehosteten Stufe zu ermöglichen, da einige Plugins in der spezifischen Stufe möglicherweise nicht benötigt werden.
Tatsächlich habe ich einen Beitrag von vor langer Zeit bezüglich gebündelter Chats verpasst und versucht, ihn zu installieren. Ich glaube nicht, dass das Tag für das Plugin aktualisiert wurde. Natürlich hat es die Website zum Absturz gebracht, da es nicht mochte, zu versuchen, das Plugin zu installieren, wenn es theoretisch vielleicht den Eintrag ignorieren könnte, mit einem abgeschlossenen Rebuild, der rät, dass es entfernt werden könnte, da es unnötig war.
Angesichts der jüngsten Initiative, mehr offizielle Plugins in den Core aufzunehmen, fragte ich mich, ob das „Who’s Online“-Plugin für die Aufnahme in Betracht gezogen wird.
Ich habe bemerkt, dass es auf den offiziellen Hosting-Plänen verfügbar ist (wird bei der Plugin-Quote berücksichtigt), daher bin ich neugierig, ob dies auf eine breitere Akzeptanz hindeutet.
Ich verstehe vollkommen, wenn Leistungseinschränkungen oder die philosophische Passform bedeuten, dass es standardmäßig deaktiviert bleiben sollte, es sei denn, es wird in der app.yml anders angegeben.
Wir haben derzeit nicht vor, weitere Plugins in den Kern zu verschieben. Cakeday war das letzte, und musste wegen einiger Komplikationen mit der Art und Weise, wie es zuvor standardmäßig aktiviert war, separat von der Hauptcharge behandelt werden.
Ich verstehe die Frustration über den Prozess hier vollkommen – er ist sicherlich nicht so reibungslos, wie ich es mir wünschen würde. Um etwas Kontext zu geben: Das grundlegende Problem ist, dass die app.yml-Dateien keine Discourse-Konfigurationsdateien sind. Sie sind eine pups-Konfiguration, und die Zeilen zur Plugin-Installation sind nur Shell-Befehle.
Discourse-spezifische Logik in pups einzubringen und es bestimmte Shell-Befehle ignorieren zu lassen, ist keine wirkliche Option. Dieses Werkzeug wird nicht nur für Discourse verwendet. Außerdem vermute ich, dass eine Reihe von Leuten unglücklich darüber wären, wenn wir die Shell-Befehle, die während des Bootstrap ausgeführt werden, ohne ihr Wissen ändern würden.
Daher sind wir mit den verfügbaren Werkzeugen zu der saubersten Lösung gelangt, die wir finden konnten: einen CLI-Neustart erzwingen und dann eine Nachricht anzeigen, die die Leute auffordert, die betroffene Zeile aus ihrer Konfiguration zu entfernen.
Denken Sie sorgfältig nach, bevor Sie dieses Plugin installieren
Ich denke, „installieren“ könnte dort besser als „aktivieren“ formuliert werden – wenn das technisch korrekt ist.
Die aktuelle Formulierung könnte den Eindruck erwecken, dass das Vorhandensein zusätzlicher gebündelter Plugins ein philosophisches oder leistungstechnisches Problem darstellt – wenn es eigentlich nur darum geht, ob sie aktiviert sind. Da ein neu hinzugefügtes Kern-Plugin, das zuvor nicht aktiviert war, nach einem Rebuild standardmäßig deaktiviert ist, liegt das Risiko nicht darin, es mit dem Kern zu installieren, sondern darin, es einzuschalten.
Diese spezielle Problematik wurde nun (größtenteils) für die gebündelten Plugins gelöst, aber bei anderen Plugins könnte dies hier und da immer noch vorkommen.
Das Plugin discourse-categories-suppressed fügt eine einfache, optionale Benutzeroberfläche hinzu, um ausgewählte Kategorien aus dem Feed „Neueste“ auszublenden. Es integriert sich über ein einzelnes Dropdown-Menü unter:
Admin → Einstellungen → Kategorien
„Kategorien, die von der Homepage unterdrückt werden“
Dies scheint eine sehr natürliche Kerneinstellung zu sein – insbesondere da:
• Sie offiziell und aktiv gepflegt wird
• Sie standardmäßig deaktiviert bleibt, es sei denn, ein Administrator aktiviert sie
• Viele Communities (einschließlich meiner) „Neueste“ als primäre Ansicht nutzen und eine feinere Kontrolle darüber wünschen, was dort erscheint
Würde das Team erwägen, dieses Plugin zu bündeln (immer noch standardmäßig deaktiviert), damit Administratoren diesen Schalter nutzen können, ohne zusätzliche Installationen vornehmen zu müssen?
Vielen Dank für Ihre Überlegung – es scheint eine kleine UI-Präferenz zu sein, von der viele Websites profitieren würden, wenn sie sofort verfügbar wäre.
