Zum Wechseln ändern Sie einfach Ihre Konfiguration und ersetzen Sie das vorhandene babble-Repository durch: https://github.com/PuttyTribe/babble.git, und bauen Sie es neu.
ooo, das Timing! Keine Aktivität seit einer Woche, und dann zwei Lösungen im Abstand von 20 Minuten!
Ich habe ursprünglich diese Lösung gewählt, mich dann aber für eine allgemeine Lösung entschieden, da der Parameter in keinem Fall verwendet wird.
Ich habe den PR von @merefield zusammengeführt, der das Problem hier behebt.
@ti0 Danke auch für den PR. Das Argument wird tatsächlich verwendet Wenn du super ohne Argumente aufrufst (also statt super()), werden die Argumente der Unterklasse automatisch an super weitergegeben. Wenn du dir die Methode ansiehst, die überschrieben wird, siehst du, wo das Argument verwendet wird: discourse/lib/search.rb at main · discourse/discourse · GitHub.
@ti0@merefield Als Randbemerkung: Wir sollten einen PR in das Discourse-Kernsystem einreichen, um einen Hook hinzuzufügen, der es Plugins ermöglicht, neue type_filters in die Search-Klasse einzufügen. Das wäre performanter und stabiler als das Patchen der execute-Methode. Das könnte ein interessantes kleines Projekt sein, wenn du es schaffst, das Discourse-Team davon zu überzeugen, dass dies eine sinnvolle Ergänzung ist.
@justin Hast du das Problem schließlich gelöst? Ich hatte dasselbe Problem, bis ich in meinem eigenen Branch die Art und Weise geändert habe, wie Babble seine Engine lädt. Ich vermute, es hat etwas damit zu tun, wie verschiedene Umgebungen @gdpelicans Methode zum Laden von Dateien im Initialisierer behandeln, also:
Es ist schwer, das genau zu lokalisieren. Ich könnte einen PR erstellen, um die Babble-Dateilademethode zu aktualisieren, und schauen, ob @gdpelican damit einverstanden ist, dies auf die Standard-Discourse-Plugin-Methode umzustellen, bei der load mit File.expand_path anstelle von require mit Rails.root verwendet wird.
Edit: Ich habe Babble auch zu try.thepavilion.io hinzugefügt, damit du es in einer Umgebung testen kannst, die alle 24 Stunden aktualisiert wird.
Falls in Zukunft ein kritischer Fehler bei Babble auftritt (d. h. es funktioniert überhaupt nicht) und James nicht verfügbar ist, markiere bitte @angus oder @merefield, und wir werden es beheben (oder einen PR prüfen ).
Ich meinte, dass der Parameter innerhalb der überschriebenen Methode, die wir geändert haben, nicht verwendet wird. Basierend auf dem, was du sagst, sollte mein Code trotzdem funktionieren, da der super-Aufruf einfach **args weitergeben würde, was benannte Argumente sammelt, und das ist stabiler, falls in Zukunft weitere Parameter hinzugefügt werden. Ergibt das Sinn? Oder übersehe ich da etwas?
Ich habe gerade einen kleinen Test durchgeführt, und dein Ansatz scheint auch für den unmittelbaren Zweck zu funktionieren (d. h. er erhält die Funktionalität von readonly_mode). Es ist jedoch etwas konzeptionell seltsam, wenn man bedenkt, dass **args theoretisch bereits vor dem Aufruf der Superklasse festgelegt werden sollte. Persönlich (und vielleicht hätte James eine andere Meinung) bevorzuge ich weiterhin die explizitere Variante, da wir die Argumente ohnehin bereits implizit über den einfachen Aufruf von super weitergeben. Zusätzliche Implizitheit durch **args wirkt hier etwas zu komplex.
Auch wenn ich verstehe, worauf du hinauswillst, finde ich es insgesamt besser, in solchen Situationen nach einer expliziten Lösung zu suchen, um Konflikte mit dem Kerncode zu vermeiden, anstatt auf allgemeine implizite Methoden zurückzugreifen. Dieser Ansatz führt tendenziell zu weiteren Problemen im weiteren Verlauf. Wie oben erwähnt, würde ich es bevorzugen, wenn wir dies durch die Einführung eines neuen type_filter im Kerncodebase refaktorisieren könnten. Das wäre meiner Meinung nach ein gutes kleines Projekt.
Hat jemand bereits Memberful integriert und festgestellt, dass der echte Name der Benutzer unter ihrem Kontonamen im Chat angezeigt wird?
Ich würde gerne verhindern, dass ihr echter Name angezeigt wird, wenn das möglich ist.
Edit: Ich habe eine vorübergehende Lösung gefunden: Mitglieder verwenden bei der Anmeldung ihren Spitznamen als vollständigen Namen, oder ich ändere manuell ihren vollständigen Namen nach der Registrierung so, dass er mit dem Spitznamen übereinstimmt.
@angus, du bist derzeit wahrscheinlich der am besten verfügbare Babble-Helfer. Deshalb melde ich mich bei dir mit einer Anfrage zu einem Code-Update, auch wenn ich mich freuen würde, wenn jemand anderes sich darum kümmert.
Ich habe unsere Discourse-Version gerade auf 2.6.0beta2 aktualisiert (genauer gesagt diese GitHub-Commit-Version), und der Emoji-Picker funktioniert jetzt nicht mehr.
@itsbhanusharma unterstützt uns bei der Discourse-Installation, und seine erste Vermutung ist ein Kompatibilitätsproblem mit dem Update des Emoji-Pickers im Discourse-Kern.
Problem mit dem Emoji-Picker
Umgebung:
Browser: Firefox oder Chrome (aktuellste Version)
Ansicht: Desktop, Tablet und Mobil
Möglichkeit, das Problem zu reproduzieren: 100 %
Schritte zur Reproduktion:
Ein Babble-Chatfenster öffnen.
Auf das Emoji-Picker-Symbol klicken oder die entsprechende Taste drücken.
Erwartetes Ergebnis:
Die Benutzeroberfläche des Emoji-Pickers öffnet sich.
@angus oder jemand anderes, der über die technischen Fähigkeiten verfügt, um Babble zu unterstützen – besteht irgendeine Hoffnung, dass die beiden Probleme, die ich vor drei Wochen in dieser Forum-Antwort gemeldet habe, behoben werden?
Hallo @angus, danke für deine harte Arbeit an diesem Plugin!
Mein Discourse-System funktioniert mit einer benutzerdefinierten Basis-URL für Long Polling. Da ich gerade Babble hinzugefügt habe, stelle ich fest, dass keine Access-Control-Header (CORS) hinzugefügt werden, was dazu führt, dass eine Reihe von Anfragen fehlschlägt.
Ich könnte möglicherweise eine Lösung schreiben, wenn du mich in die richtige Richtung im Code weisen könntest.
Nach der Installation der neuesten Discourse-Updates und der neuesten Version von Babble (vor ein paar Tagen und erneut gestern, um zu prüfen, ob das Problem behoben ist), habe ich Probleme beim Senden von Nachrichten, und der Lese-Indikator zeigt weiterhin festgefroren an, dass neue Nachrichten vorhanden sind.
Gerade als ich keine Nachricht senden konnte, erhielt ich im Browser-Console eine Reihe dieser Fehlermeldungen:
Uncaught Error: No Reason Phrase
jQuery 13
error _application-49dab3118e527975ea48703627a0152cbe26663b7fde8423c667b094d716ae08.js:8967
jQuery 4
_ember_jquery-865569b174cc91f4563f3552f437b32c6eadf9f6c3d49eae02cfe50e5a8c7dfa.js:38573:14
jQuery 13
u self-hosted:1177
error _application-49dab3118e527975ea48703627a0152cbe26663b7fde8423c667b094d716ae08.js:8967
jQuery 4
Keine Aktivität seit einer Woche, und dann zwei Lösungen im Abstand von 20 Minuten!
