由于@gdpelican 在过去一周内未作回应，已创建修复并提交 PR。在修复合并到主仓库之前，您可以使用备用仓库。
备用仓库：https://github.com/PuttyTribe/babble
PR：Fix issue with search controller by ti0 · Pull Request #302 · gdpelican/babble · GitHub
切换方法：只需修改配置，将现有的 babble 仓库替换为 https://github.com/PuttyTribe/babble.git，然后重新构建。
时机真巧！
一周没动静，紧接着 20 分钟内就来了两个解决方案！
我最初确实选了那个方案，但后来决定直接采用一个通用方案，因为这个参数在任何情况下都没被用到。
我已合并 @merefield 的 PR，该 PR 修复了此处的问题。
@ti0 也感谢你的 PR。这个参数实际上是被使用的 如果你调用 super 时不带参数（即不使用 super()），子类的参数会自动传递给 super。如果你查看被重写的方法，就能看到该参数在何处被使用：discourse/lib/search.rb at main · discourse/discourse · GitHub
@ti0 @merefield 顺便提一下，我们应该向 Discourse 核心提交一个 PR，在 Search 类中添加一个钩子，以便从插件中添加工新的 type_filters。这比直接修补 execute 方法更高效、更稳定。如果你能说服 Discourse 团队认为这是一个有价值的补充，这或许会成为一个有趣的小项目。
@justin 你最终解决这个问题了吗？我也遇到了同样的问题，直到我在我自己的分支中改变了 Babble 加载其引擎的方式。我怀疑这与不同环境如何处理 @gdpelican 在初始化器中加载文件的方法有关，即：
require Rails.root.join('plugins', 'babble', 'app', path).to_s
很难确切定位。我可能会提交一个 PR 来更新 Babble 的文件加载方法，看看 @gdpelican 是否同意将其改为 Discourse 插件的标准方法，即使用 load 配合 File.expand_path，而不是使用 require 配合 Rails.root。
编辑 我还已将 Babble 添加到 try.thepavilion.io，这样你就可以在一个每 24 小时更新一次的环境中进行测试。
未来，如果 Babble 出现严重错误（即完全无法使用），而 James 又无法联系，请 @angus 或 @merefield，我们会修复它（或审查 PR :)）。
我的意思是，在我们修改的那个被重写的方法内部，该参数并未被使用。根据你所说的，我的代码应该仍然可以工作，因为 super 调用只会传递 **args，它收集了命名参数，而且如果将来添加其他参数，这种方式会更稳定。这样理解对吗？还是我漏掉了什么？
是的，你说得对
我刚做了一个小测试，你的方法在直接目的上似乎也能奏效（即它保留了 readonly_mode 的功能）。不过从概念上讲，这有点奇怪，因为理论上 **args 应该在调用父类之前就已经设置好了。就我个人而言（也许 James 会有不同的看法），我仍然更倾向于更明确的方式。既然我们调用 super 时已经在隐式传递参数了，再用 **args 增加一些隐式性，感觉会变得过于复杂。
虽然我理解你的意图，但权衡之下，我认为在这种情况下更好的做法是寻找一种明确的方式来避免与核心代码冲突，而不是依赖这种通配性的隐式方法。这种做法往往会在后续引发其他问题。正如上面提到的，我更希望能通过重构，在核心代码库中添加一个新的 type_filter 来实现。我认为这会是一个不错的小项目。
是否可以全局默认将所有用户的“页面加载时自动打开聊天窗口”设置为“是”？
是否可以让 URL 在 Babble 中像在线程中那样渲染？
例如，在 Babble 聊天中发布一条推特链接时，显示推文内容而不是仅仅显示 URL。
有人集成过 Memberful 吗？之后用户的真实姓名是否显示在聊天中其账户名称下方？
如果可以的话，我想隐藏他们的真实姓名。
编辑：我有一个临时解决方案，让会员在注册时使用其屏幕名称作为全名，或者在他们加入后手动将他们的全名修改为与屏幕名称一致。
截至 2020 年 9 月 17 日，有人在使用这个吗？
只是想确认一下，这是否只是一个副业项目。
@angus，您可能是目前最空闲的 Babble 助手。因此，我向您发送此代码更新请求，当然，也欢迎任何人来处理这个问题。
我们刚刚将 Discourse 版本更新到了 2.6.0beta2（具体是 这个 GitHub 提交版本），现在表情选择器已无法正常工作。
@itsbhanusharma 负责我们的 Discourse 安装，他的初步判断是这与 Discourse 核心中表情选择器的更新存在兼容性问题。
环境：
浏览器：Firefox 或 Chrome（最新版本）
视图：桌面、平板和移动设备
问题复现率：100%
复现步骤：
预期结果：
表情选择器界面打开
实际结果：
无任何反应。表情选择器窗口未打开。
如果不会增加复杂性，修复表情选择器问题的人可能也顺便修复一个缺失的翻译。
当您点击聊天消息旁边的“…”图标时，“标记”选项显示为“[en_US.post.actions.flag]”，而不是“标记”。
Babble 中的表情符号选择器在我的网站上也无法使用了。
另外，我的聊天窗口也会随机向上滚动。我认为之前也出现过这个问题。
@angus 或任何如今具备技术能力帮助 Babble 的人——你们是否有希望修复我在三周前于本论坛回复中报告的两个问题？
Joel，感谢你的及时回复。
我已添加对新 Discourse 表情选择器的支持
我也已处理了这个问题。
你好 @angus，感谢你为这个插件付出的辛勤努力！
我的 Discourse 系统使用自定义的长轮询基础 URL。由于我刚添加了 Babble，我发现它没有添加任何跨域资源共享（CORS）的 Access-Control 头，导致许多请求失败。
如果你能指点我代码中的正确方向，我或许可以编写一个修复方案。
在安装最新的 Discourse 更新以及最新版本的 Babble 后（几天前安装过一次，昨天又安装了一次以确认问题是否已修复），我遇到了发送消息的问题，同时未读消息指示器也卡住，一直显示有新消息。
就在刚才，当我无法发送消息时，浏览器控制台中出现了一堆如下错误：
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
在论坛账户列表中检测到用户名异常（以“f5c…”开头，例如 f5cfe2e6cc098d）的账户 — This is the problem of a specific user or something else?
您的插件以前遇到过此类问题吗？
