我很想提供更多细节，但遗憾的是，我只能根据这条尽可能无用的错误信息来排查：
发布此帖子到 Discourse 时发生错误。
我在网站或 Discourse 上看到的任何错误日志中都没有相关内容。
我可以链接到一个现有主题，但这与直接更新帖子元数据相比，帮助微乎其微。
我是否错过了设置中的某个调试开关？或者还有其他方法可以获取更有用的错误信息吗？
你打开浏览器中的网页开发控制台并检查 JS 控制台是否有错误了吗？
现在有——没什么值得注意的，当然也没有关于 Discourse 的内容。
在深入挖掘了一些本不该查看的内容后，我得到了一个错误信息：
无法验证 CSRF 令牌的真实性。
这几乎和原来的信息一样没什么帮助。
由此我得出以下结论：
- 2.6.0.beta1 版本存在故障，
- 升级是个错误，因为似乎无法回滚到 2.5.0 版本，
- discourse 和/或 wp-discourse 的单元测试需要进一步完善，
- 在问题最终修复之前，我彻底束手无策，因为似乎无法手动为某个主题设置
embed_url。
我想这也算是一种“解决方案”吧……
很抱歉回复晚了。我一直在关注 Support > WordPress 分类，但我很确定没有收到该主题的通知我。获取详细错误信息的最简单方法是安装 Query Monitor – The developer tools panel for WordPress – WordPress plugin | WordPress.org English (Canada) Discourse。WP Discourse 插件曾经将所有错误保存到日志文件中，但由于这不符合 WordPress 的建议，现已停止这样做。您尝试发布任何帖子到 Discourse 时都会出现错误，还是仅特定帖子出现问题？Discourse 升级到 2.6.0.beta1 似乎不太可能是导致该问题的原因。在插件停止为您工作时，您的 WordPress 站点是否进行了任何更改？
该错误仅在 Docker 容器中的 production.log 中显示——其他任何日志或控制台中都没有（我已经运行了 Query Monitor）。
任何新帖子都会出现。
只是将插件更新到了 2.0.6。不过，问题并不在插件本身——我已经通过 git 标签逐步回退，但没有任何进展。
我很惊讶 Query Monitor 插件没有显示任何错误。我原本预期会看到类似这样的提示，只是错误信息不同：
或许值得从您的 Discourse 管理后台 / API 页面重新生成一个新的 API 密钥。请确保该密钥是全局密钥（允许所有操作）。同时，请确认在 WP Discourse 连接设置标签页中，“发布用户名”已正确设置。既然您能够链接到现有的 Discourse 主题，但无法发布新主题到 Discourse，问题很可能与 API 权限有关。
最后，请检查一下当您尝试从 WordPress 向 Discourse 发布文章时，文章的自定义字段被设置成了什么值。如果在编辑器中启用了自定义字段，您应该在编辑器底部看到类似以下内容：
如果您能告诉我哪些字段被设置了，我或许就能找出问题的原因。
我也是，但它确实什么都没有显示。如果显示了，那应该是一个 400 错误（因为 production.log 中报告的就是这个），但实际上并没有。
更新：我在代码里仔细查找后，发现确实不会有错误——所有情况都被捕获了；如果你启用了邮件报告（有邮件但没有 error_log()？），它会告诉你：
失败原因：
Discourse 返回了 400 响应码。
请求错误
仅此而已。
已经这样做了，没有任何区别。这是最后的尝试——当我尝试发布时，上一个密钥的“最后使用时间”戳已更新，所以我确定它没有发生任何变化，但我还是想试一试。
publish_post_category: 23
update_discourse_topic: 0
wpdc_publishing_error: 请求错误
wpdc_unlisted_topic: 1
就这些。哦，在你问之前，即使我不设置“作为未列出发布”，结果也是一样的，只是帖子元数据的预期值有所不同。
感谢提供详细信息。我周一回到工作岗位后会再仔细查看一下。
我不确定是什么导致了 400 响应。您能否尝试安装 Health Check & Troubleshooting – WordPress plugin | WordPress.org English (Canada) 并查看它是否报告了 WordPress 站点的任何问题？激活该插件后，您的 WordPress 仪表板的“工具”部分将添加一个“站点健康”条目。点击该链接并进入“状态”选项卡，可能会显示一些有用的详细信息。
健康检查插件还允许您仅针对自己的会话临时禁用插件。这对于查看问题是否与另一个插件冲突非常有用——如果您的站点安装了任何与安全相关的插件，不妨尝试禁用它们，看看是否能解决问题。
不幸的是，我遇到了死胡同。健康检查插件没有提供任何有用的建议（这并不意外），而其他一切功能都运行正常。
我在自动化发送邀请时遇到了 CSRF 错误，这通常意味着代码中存在错误；但在这种情况下，插件本身并未更改，因此我的结论是 2.6.0.beta1 版本存在故障。
我知道这个结论可能不太受欢迎，但目前这是我唯一的判断。
编辑补充：我使用健康检查插件禁用了所有其他插件，但结果没有任何变化。
问题在 2.6.0.beta2 和 2.1.2 版本中仍然存在。