Google Chrome のモバイル版、Firefox のモバイル版（またはその他のモバイルブラウザ）を使用して、問題を再現してみてください。
「いいね！」 2
キャッシュのクリアで解決しました！ありがとう！編集：いや、ダメでした。
「いいね！」 1
ここがおろそかになってしまい申し訳ありません。他の仕事で忙しくしていました。このプラグインも近いうちに再確認します。
@DaleKramer @Hifihedgehog 緊急性のある問題があればお知らせください。今週中に確認いたします。
「いいね！」 4
thePavilion.io にクイックメッセージを再度追加しました。そこで問題を再現できますか？
「いいね！」 1
もしかしたら、このプラグインが原因である可能性を示した私が直面したこの問題をご覧いただけますか…
最新バージョンではクイックメッセージが機能していません。すべてのメッセージで以下のプロンプトが表示されます。
申し訳ありませんが、既存のトピックにプライベートメッセージを作成することはできません。
はい、私も同じエラーが発生しています：申し訳ありませんが、既存のトピックにプライベートメッセージを作成することはできません。
「いいね！」 1
同じ「PM を作成できません」というエラーが発生しています。このコミットが原因でしょうか？
ご報告ありがとうございます。できるだけ早く確認いたします。
「いいね！」 1
これが問題でした。修正方法は、このコミットの変更を含まずに valid? 関数を上書きすることです。
したがって、plugin.rb などで以下のようにしてください。
require_dependency ‘post_creator’
class ::PostCreator
def valid?
ここに 4 行分を除いて書き換えてください
明日までに誰かがやらないなら、朝から見ていたので、自分でもPRを出すかもしれません。
「いいね！」 4
それはとてもありがたいです。今はかなり忙しい状況で、少し困っています 
。ありがとうございます！
「いいね！」 1
「いいね！」 1
できるだけ早く修正してほしいのですが、この修正の長期的な使い勝手についても懸念しています。その関数のコア実装内のロジックが変更されたらどうなるでしょうか？
「いいね！」 1
ああ、同意します。これはやり方が間違っています。特に valid? メソッドを使う場合、セキュリティ脆弱性が発生するのを待っているようなものです。Discourse がその点で次の WordPress にならないよう注意したいですが、良い代替案はあるでしょうか？
私も最近、このような問題に悩まされています。多くのチェックを含む長いメソッドがあり、その真ん中にある単一のチェックだけを回避したいという状況です。
:create_pm_on_existing_topic が唯一のエラーかどうかを単純に確認することはできません。なぜなら、そのエラーが設定されるとコードは即座に返却され、その後にも他のチェックで失敗している可能性があるからです。
少なくとも、このモジュールをプリペンドし、新しい valid? メソッドでクイックメッセージのシナリオかどうかを確認すべきです。クイックメッセージであれば、修正された検証コードを実行し、そうでなければ return super を呼び出してコアコードを実行します。コア関数が変更された場合でも、プラグインの機能のみが影響を受け、フォーラムソフトウェア全体が壊れることはありません。
削除されたチェックが以下のコードだったことを特定するために、2 つの関数を行ごとに比較する必要がありました。
if new_topic?
...
else
if @topic.present? && @opts[:archetype] == Archetype.private_message
errors.add(:base, I18n.t(:create_pm_on_existing_topic))
return false
end
...
コメントがあれば助かったのにね 
このようなモンキーパッチを保守可能な状態で保つためのより良い方法をご存知の方はいらっしゃいますか？
（実際に「モンキーパッチ」と「保守可能」という言葉を同じ文の中で使いましたか？
）
実は、[FIX: 既存のトピック上で新しい PM を作成しないようにする #9029] によって、なぜクイックメッセージが壊れてしまうのか、まだよくわかりません。9029 の修正は PM とトピックには機能するのですが、なぜクイックメッセージが壊れてしまうのでしょうか？クイックメッセージが新しい PM を投稿する特定の方式が、9029 と競合しているのでしょうか？
はい、その通りだと思います。そして #9029 でその特定のチェックが追加されました。
このプラグインの修正版をプッシュしました。結果を教えてくださいね。
@Oliver_Walker PR をありがとうございます。他の人が言っている通り、大きなメソッドをオーバーライドするのは避けたほうが良いですが、挑戦してくれてありがとう 
95% のケースで、大きなサーバーサイドメソッドの一部をオーバーライドしようとするときは、古びた占いクッキーのように聞こえるかもしれませんが、あなたはフレームワークのロジックに逆らっていることになります（例外がいくつかあるかもしれません）。
この場合、最初に問うべきことは：通常の PM は既存の通常の PM トピックにどう追加されるのか？実は、問題の原因は、プラグインがトピックを作成する最初の投稿だけでなく、すべての投稿に private_message 型を割り当てようとしていたことです。
「いいね！」 5
@angus さん、ありがとうございます。これをテストできたとお見受けしましたが、合っていますか？また、ホスティングパートナーである Communiteq（旧 DiscourseHosting）にプラグンの再読み込みを依頼するだけでよいのでしょうか？