请尝试使用移动版 Google Chrome 或移动版 Firefox（或其他任何移动浏览器）复现该问题。
2 个赞
清除缓存果然有效！谢谢！编辑：好像又没用了。
1 个赞
抱歉这里有些疏忽，我一直在忙其他工作。很快会再次查看这个插件。
@DaleKramer @Hifihedgehog 如果有紧急问题请告诉我，我本周会查看。
4 个赞
我已将快捷消息重新添加到 thepavilion.io。你能在那里复现这个问题吗？
1 个赞
或许您可以查看一下我遇到的这个问题，它似乎指向该插件是罪魁祸首：查看问题…
在最新版本中，快速消息功能已损坏，每条消息都会出现以下提示：
抱歉，您无法在现有主题上创建私信。
没错，我也遇到同样的错误：抱歉，您无法在现有主题上创建私信。
1 个赞
收到相同的“无法创建私信”错误。这是否与该提交有关？
感谢提交报告。我会尽快查看。
1 个赞
这就是问题所在。修复方法是覆盖 valid? 函数，但不包含此提交中的更改。因此，在 plugin.rb 或其他地方执行以下操作：
require_dependency 'post_creator'
class ::PostCreator
def valid?
# 在此处重写，减去 4 行代码
end
end
如果明天没人做，我可能会为这个提个 PR，毕竟我整个上午都在研究它。
4 个赞
那真是太感谢了。目前事情相当繁忙 
。谢谢！
1 个赞
虽然我很希望能尽快修复这个问题，但我也担心该修复方案的长期可用性。如果该函数核心实现中的逻辑发生变化怎么办？
1 个赞
是的，我同意，这不是正确的做法……尤其是对于 valid? 方法来说，这简直就是在等待安全漏洞的发生……我们可不想 Discourse 在这方面成为下一个 WordPress……但有什么好的替代方案呢？
最近我也一直在为这类问题头疼：一个包含大量检查的长方法中，我只想绕过其中某一项检查，而且就在这个方法的中间部分。
你不能仅仅检查 :create_pm_on_existing_topic 是否是唯一的错误，因为代码一旦设置了该错误就会立即返回，而且在那之后可能还有其他检查也失败了。
我至少会先引入这个模块，然后在新的 valid? 方法中判断这是否属于“快速消息”场景。如果是，就运行修改后的验证逻辑；如果不是关于快速消息的，就直接 return super，调用核心代码。这样，即使核心函数发生变化，也只会影响插件功能，而不会破坏整个论坛软件的其他部分。
我不得不逐行对比这两个函数，才发现被移除的检查是：
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
...
加个注释也不会怎么样吧 
有人知道更好的方法，能确保这类“猴子补丁”易于维护吗？
（我居然在一句话里同时用了“猴子补丁”和“可维护”这两个词？
）
实际上，我仍然不确定为什么快捷消息会被 [修复：确保我们不会在已有主题上尝试创建新私信 #9029] 破坏？9029 修复对私信和主题都有效，那为什么快捷消息会出问题？是否是因为快捷消息创建新私信的某种特定方式与 9029 存在冲突？
是的，我想就是这个问题。而且 #9029 确实添加了那个特定的检查。
我刚刚为这个插件提交了一个修复。请告诉我效果如何。
@Oliver_Walker 感谢你的 PR。正如其他人提到的，最好不要重写大型方法，但还是要感谢你的尝试 
冒着听起来像陈词滥调的风险，在 95% 的情况下，当你考虑重写大型服务器端方法的一部分时，你实际上是在与框架的逻辑对抗（也许有少数例外）。
在这种情况下，首先要问的问题是：普通的私信是如何被添加到现有的普通私信主题中的？问题在于，该插件试图将 private_message 架构分配给每一篇帖子，而实际上应该只分配给创建该主题的第一篇帖子。
5 个赞
谢谢 @angus。我假设您已经测试过了？另外，我是否只需联系我们的托管合作伙伴（Communiteq（原 DiscourseHosting））让他们为我们重新加载插件？