Maker Forums のメンバーは、複数の絵文字リアクションができる機能を確かに評価しています。retort がメンテナンスされなくなってしまう場合、その機能を移行で失うのは非常に残念でしょう。
「いいね！」 3
Retort は引き続き Pavilion によってメンテナンスされます。
@Ahmed_Gagan 以下の件についてご意見はありますか？
「いいね！」 5
優先度の高いリトート反応を行うには、以下を使用してください。
SiteSetting.post_undo_action_window_mins = 最大許可分钟数
ReactionManager.new(first_retort_reaction_at_priority, by_user, Guardian.new(by_user), post).toggle!
これで全て処理されます。ユーザーがすでに投稿に「いいね」をしている場合はそれを削除し、反応を追加します。
「いいね！」 1
はい、それなら可能です。ただ、少しハック的な手法にはなりますが 
その回避策が長期的に有効であり続けるとは限りませんし、リスクも伴います。例えば、そのコードを実行しただけでは、ユーザーの post_undo_action_window_mins サイト設定が変更されたままになってしまいます。マイグレーションの最後にもとの値に戻すことは可能ですが、ガードを回避するためにその場で設定を変更するのは理想的ではありません。
私が目指しているのは、リトートをリアクションへ確実に移行できるようにするために、ReactionManager インターフェースを少し変更することです。現状ではクライアントからのリクエストのみを処理するように設計されています。
そのための一つの方法として、以下のアプローチが考えられます：
toggle!内のガードをensure_can_toggleメソッドに抽象化するensure_can_toggleメソッドにforceオプションを追加する
これは、Discourse の他の部分でもマイグレーションやバックエンドからのインポートを処理する際に一般的に採用されているアプローチです（app/ または lib/ 内で force を検索すると、いくつかの例が見つかります）。
これで意味が通じますか？
「いいね！」 2
ここでの設定は不要だと考えます。既存の投稿の「いいね」には触れないため、新しいリアクションを作成することになります。この場合、guardian.can_delete_reaction_user? は常に true になります。個人的には、この目的には ReactionManager.toggle を使用するだけで十分です。
「いいね！」 1
Discourse では、信頼レベルによる「いいね」数の制限や、いいね数に基づくバッジ付与など、いいねを多く活用しています。
リアクションを追加すると、ユーザーとトピックの両方の「いいね」数にカウントされますか？
「いいね！」 1
この新しい公式プラグインとの連携について個別に質問することもできます: Discourse Reactions
ただし、Retort（Discourse Reactions プラグインとは異なり、投稿ごとにユーザーが複数のリアクションを追加できる機能を提供します）は、「いいね」に関連する信頼レベルやバッジとは一切連携しません。
「いいね！」 5
@gdpelican これは https://meta.discourse.org/t/reaction-emoji-seem-to-have-no-verification/189108 からの再投稿です。リアクションが Discourse の機能ではないようなので、ここに再投稿します：
バグを発見したと思うのですが、適切な再現手順はありません。ただし、問題の具体例は簡単に見せることができ、私の仮説が正しいと考えています。
問題は、存在しない絵文字を投稿のリアクションとして追加できてしまうことです。その結果、投稿には :whateverYouWant: のようなリアクションが表示されてしまいます。
Manjaro フォーラムでその例を確認できます。特定のユーザーの投稿によくこのような存在しない絵文字が表示されていました。彼にいくつか質問をした結果、ブラウザに何らかの自動翻訳拡張機能を使用しており、おそらく :code: 形式の絵文字を自言語に翻訳しているのではないかと結論付けました。残念ながら、彼から返信が得られず、ブラウザでの正確な設定は分かりませんでした。私の仮説を裏付けるものとして、以下のスレッドで彼が誰かを引用した際、引用元のメッセージが翻訳されていることが確認できます。
Manjaro フォーラムのこのメッセージ/スレッドをご覧ください：
リアクションの例をご覧ください。正しいリアクションの隣に無効なものが並んでいるため、問題が明確にわかります：
つまり、絵文字コードの検証がないプロセスを通じて、ユーザーが存在しない絵文字を送信できてしまうようです。
「いいね！」 1
このプラグインを最新の Discourse コードと互換性があるよう更新しました。
@th21 また、特にモバイル環境での長いリトートリストへの対応を改善するため、リトートの HTML 構造も更新しました。
「いいね！」 8
ありがとうございます、動作しました！
「いいね！」 2
リトートコンテナはツールバーの上下に配置すべきだと考えます。できれば上です。そうすれば、CSS の観点から作業スペースが大幅に広がります。
「いいね！」 2
データエクスプローラーやコンソールを使用して、最もよく使われる絵文字のリストを見つけることは可能ですか？ 
plugin_store_rows テーブルを調べてみましたが、役立つものは見つかりませんでした。
「いいね！」 3
こんにちは。ユーザーが返信でリアクションしたツールチップがモバイルで壊れています。z-indexを調整してみましたが、カスタムCSSでうまく修正できませんでした。どなたか確認していただけますか？
Discourse Reactions は、主な理由が 1 つあります。それは、投稿ごとに 1 つのリアクションに制限されることです。これは、同じ投稿に複数のリアクションを付けられる Retort と比較して、リアクションの有用性が劇的に低下します。
この理由で Retort が保守されることを強く願っています。より良い解決策は、Discourse Reactions が複数のリアクションを許可するように更新されることです。
「いいね！」 5
もう一つの大きな欠点は、Retortでは利用可能なすべての絵文字から選択できるのに対し、Discourse Reactionsでは絵文字のセットを定義する必要があることです。Discourse Reactionsにこれら両方の機能があれば、喜んでRetortを削除しますが、そうでない限り、ユーザーに絵文字リアクションの95%へのアクセスを失うと伝えても、ユーザーは満足しないでしょう。
「いいね！」 2
有望な Feature トピックがあります…
「いいね！」 3
はい、これがすべて実装されれば、ユーザーベースに移行を簡単に説得できると思います。これが完全に利用可能になる前に代替手段を廃止するのは、少し残念なだけです。
「いいね！」 3