Mitglieder in den Maker-Foren schätzen definitiv die Möglichkeit, mehrere Emoji-Reaktionen zu hinterlassen. Wir wären sehr traurig, dies bei einer Migration zu verlieren, falls retort nicht mehr gewartet werden sollte.
Retort wird weiterhin von Pavilion gewartet.
@Ahmed_Gagan Hast du dazu Gedanken?
[quote=“angus, post:435, topic:35903”]
Es ist möglich, dass ein Nutzer einen Beitrag sowohl geliked als auch „retortet
Für eine Retort-Reaktion mit Priorität können Sie Folgendes verwenden:
SiteSetting.post_undo_action_window_mins =max erlaubte Minuten
ReactionManager.new(first_retort_reaction_at_priority, by_user, Guardian.new(by_user), post).toggle!
Dies übernimmt alles: Es entfernt das like, falls der Benutzer den Beitrag bereits geliked hat, und fügt eine Reaktion hinzu.
Ja, das könnte ich machen. Es wäre zwar ein bisschen ein Hack ![]()
Ich bin mir nicht sicher, ob ich davon ausgehen kann, dass dieser Workaround langfristig tragfähig bleibt. Es ist auch etwas riskant. Wenn ich diesen Code einfach ausführe, würde die Site-Einstellung post_undo_action_window_mins des Benutzers dauerhaft geändert bleiben. Man könnte sie zwar am Ende der Migration wieder zurücksetzen, aber solche Einstellungenänderungen auf dem Sprung vorzunehmen, um einen Guardian zu umgehen, ist nicht ideal.
Ideal wäre hier eine leichte Änderung an der Schnittstelle von ReactionManager, um eine zuverlässige Migration von Retorts zu Reaktionen zu ermöglichen. Derzeit ist sie nur so konzipiert, dass sie Anfragen vom Client verarbeitet.
Eine Möglichkeit dafür wäre:
- den Guardian in
toggle!in eine Methodeensure_can_togglezu abstrahieren - die Methode
ensure_can_toggleum eine Optionforcezu erweitern
Dies ist der Ansatz, der typischerweise in anderen Bereichen von Discourse für Migrationen oder Backend-Imports verwendet wird (wenn du in app/ oder lib/ nach force suchst, findest du einige Beispiele).
Macht das Sinn?
Ich denke, wir müssen die Einstellung hier nicht verwenden, da wir die bereits auf dem Beitrag erstellten Likes nicht ändern. Das bedeutet, dass wir neue Reaktionen auf den Beitrag erstellen. In diesem Fall wird guardian.can_delete_reaction_user? immer true sein. Meiner Meinung nach reicht es aus, ReactionManager.toggle zu verwenden.
Discourse leistet mit Likes viel, etwa durch die Begrenzung der Anzahl der Likes je Vertrauensstufe und die Vergabe von Abzeichen basierend auf Likes.
Führt das Hinzufügen einer Reaktion auch zur Likes-Anzahl für sowohl Benutzer als auch Themen?
Du könntest separat fragen, wie dies mit dem neuen offiziellen Plugin Discourse Reactions interagiert.
Retort (das im Gegensatz zum Discourse-Reactions-Plugin mehrere Reaktionen pro Beitrag pro Benutzer erlaubt) interagiert jedoch überhaupt nicht mit den mit Likes verbundenen Vertrauensstufen und Abzeichen.
@gdpelican Dies ist ein Neuposting aus https://meta.discourse.org/t/reaction-emoji-seem-to-have-no-verification/189108, da die Reaktionen scheinbar nicht zu Discourse gehören. Ich poste sie hier erneut:
Ich glaube, ich habe einen Fehler entdeckt, habe aber keine korrekte Reproduktion. Ich kann jedoch leicht Beispiele für das Problem zeigen, und ich denke, meine Theorie könnte stimmen.
Hier ist das Problem: Man kann nicht vorhandene Emojis zu den Post-Reaktionen hinzufügen. Das führt zu Reaktionen wie :whateverYouWant: in den Beiträgen.
Ein Beispiel dafür findet sich im Manjaro-Forum, wo ich bemerkt habe, dass Beiträge eines bestimmten Benutzers oft diese nicht vorhandenen Emojis enthalten. Nach einigen Fragen an ihn kam ich zu dem Schluss, dass er eine Art automatische Übersetzungserweiterung in seinem Browser verwendet, die wahrscheinlich die Emojis :code: in seine Sprache übersetzt. Leider habe ich keine Antwort von diesem Benutzer erhalten, um genau zu erfahren, wie sein Browser eingerichtet ist. Um meine Theorie zu untermauern: Man kann sehen, dass er in dem folgenden verlinkten Thread, als er jemanden zitierte, die Übersetzung der ursprünglichen Nachricht in seinem Zitat hatte.
Siehe diese Nachricht/diesen Thread im Manjaro-Forum:
Siehe ein Beispiel in den Reaktionen: Man sieht das Problem deutlich bei allen korrekten Reaktionen neben der ungültigen:
Es scheint also, dass ein Benutzer nicht vorhandene Emojis senden kann, da keine Überprüfung des Emoji-Codes stattfindet.
Hat bei jemandem sonst auch dieses Problem aufgetreten, dass die Reaktionen auf kleinen Bildschirmen und auf Mobilgeräten verschoben werden?
Ich habe dieses Plugin aktualisiert, damit es mit dem neuesten Discourse-Code funktioniert.
@th21 Ich habe auch die HTML-Struktur von Retort angepasst, um lange Retort-Listen besser zu unterstützen, insbesondere auf mobilen Geräten.
Danke, es funktioniert!
Ich denke, der Retorten-Container sollte sich oberhalb oder unterhalb der Symbolleiste befinden, vorzugsweise oberhalb. Das gibt uns mehr Spielraum für die CSS-Entwicklung.
Ist es möglich, den Daten-Explorer oder die Konsole zu verwenden, um die am häufigsten verwendeten Emojis zu finden?
Ich habe mir die Tabelle plugin_store_rows angesehen, aber nichts Hilfreiches gefunden.
Hallo, der Tooltip, mit dem Benutzer mit Erwiderungen reagierten, funktioniert jetzt auf Mobilgeräten nicht mehr. Ich habe versucht, mit z-index herumzuspielen, konnte es aber mit benutzerdefiniertem CSS nicht erfolgreich beheben. Hat jemand eine Chance, sich das anzusehen?
Dieses Plugin ist end-of-life. Bitte verwenden Sie das Reactions Plugin.
Discourse Reactions ist aus einem wichtigen Grund ein schlechter Ersatz: Es beschränkt Reaktionen auf eine pro Beitrag. Das ist eine dramatische Reduzierung des Nutzens von Reaktionen im Vergleich zu Retort, das es den Leuten ermöglicht, mehrere Reaktionen auf denselben Beitrag zu geben.
Ich wünschte wirklich, Retort würde aus diesem Grund gepflegt werden. Die bessere Lösung wäre, Discourse Reactions so zu aktualisieren, dass mehrere Reaktionen möglich sind.
Der andere große Nachteil ist, dass Retort es Ihnen ermöglicht, aus allen verfügbaren Emojis auszuwählen, während Sie für Discourse Reactions einen Satz von Emojis definieren müssen. Wenn Discourse Reactions beide dieser Funktionen hätte, würde ich Retort gerne fallen lassen, aber bis dahin werden meine Benutzer nicht glücklich sein, wenn ich ihnen sage, dass sie den Zugriff auf 95 % der Emoji-Reaktionen verlieren.
Es gibt ein #feature-Thema, das vielversprechend ist…
Ja, wenn das alles implementiert ist, denke ich, dass ich meine Benutzerbasis leicht davon überzeugen könnte, zu migrieren. Es ist nur irgendwie ärgerlich, die Alternative einzustellen, bevor dies vollständig verfügbar ist.

