我有一个包含约1000篇旧帖子的WordPress网站。我想批量为所有这些帖子创建Discourse评论线程。看起来，如果我编辑并保存每篇帖子，且Discourse WP插件的设置正确，就会创建新的评论线程。
但是……我不想逐一打开并保存1000篇帖子。
我可以轻松地从wp_posts表中获取所需的wp_post ID和标题。也许有人知道如何编写一条SQL语句，利用wp_posts中的必要数据为Discourse创建新的线程？
您正在使用 WP-discourse 插件吗？如果是的话，我怀疑您最好在 WordPress 中自动化此操作。
（我不知道如何具体执行您要求的操作。）
是的，我正在使用该插件，并已设置为自动化模式，但要让帖子在 Discourse 中“自动”生成评论线程，需要更新对应的 WordPress 帖子，例如：打开编辑并保存。
无论如何，我觉得从 WordPress 的 MySQL 数据库中查询所需数据，并通过 SQL 将其填充到 Discourse 数据库中会容易得多。只是我对 Discourse 的数据库结构完全不了解，希望能找到熟悉它的人帮忙。
我想我也可以写一个 Bash 脚本，利用 WordPress CLI 来批量打开并保存所有帖子。哈哈，也许我真的会这么做。
问题在于，如果你在 Discourse 端操作，你的 WordPress 站点将缺乏必要的信息来正确显示链接、评论数量等。我目前也没有在任意一端实现该功能的解决方案，但我建议你将精力集中在 WordPress 上。
如果 WordPress 命令行工具允许你遍历帖子并以某种方式保存它们，从而触发 Discourse 插件按你的要求创建主题，那我肯定会这么做。这可能效率不高，但对于一次性任务来说，任何额外开销所花费的时间都比寻找一个“更好”的解决方案要少。
正如其他人所提到的，目前最简单的方法是通过 WP Discourse 插件。直接更新每个实例的数据库会引发两个潜在问题：
- 您需要了解每个实例上存储的所有数据和元数据。
- 数据和元数据是相互依赖的，例如，当文章从 WordPress 成功发布到 Discourse 后，Discourse 中该文章的 ID 会被保存到 WordPress 的文章元数据字段中。
如果您已经熟悉上述两点，那么直接更新数据库可能是一个不错的选择；但考虑到您并不熟悉，除非您愿意为此专门花时间学习，否则这并非明智之举。在这种情况下，您也可以聘请他人代为处理，但我更建议您直接使用 WP Discourse 插件的功能。
使用 WP Discourse 插件还有一个额外好处：该插件已内置了发布日志功能，这意味着如果任何发布失败，您将能够获得详细的、针对单篇文章的信息。
诚然，这意味着您的 Discourse 实例将收到约 1000 次 POST 请求，因为 WP Discourse 插件每次只发布一个主题。不过，考虑到这是一次性迁移任务，您可以通过分批处理并在脚本中设置暂停（例如使用 sleep）来应对。我建议在完成前几批后进行一次手动检查，以确认其按预期工作。
至于脚本本身，您只需对每篇文章调用 WPDiscourse\\DiscoursePublish 方法中的 publish_post_after_save 函数，即在循环中执行（并配合适当的分批和暂停）。
谢谢大家！
我没想到两边都需要进行数据库更改。这很有趣。我对 WordPress 数据库非常熟悉，甚至可以说太熟悉了。我往往在应该采用其他方法时，却首先去查数据库。
是的，我就是这样一个对数据库痴迷的傻瓜。我热爱数据库的设计和创建。但是……我（目前）对 Discourse 数据库一点也不熟悉。所以……
啊，没错……完善的日志记录确实是一件美好的事情。
是的，太好了。我将把此视为正确的答案，因为它正是我所需要的。
不过……
我最终的做法是使用 WP CLI 工具，如下所示：
$wp post update 396 398 402 {此处还有几个 ID} --tags_input=discourse
在此之前，我从 wp_posts 表中检索了所有 post_status = ‘publish’ 且 post_type = ‘post’ 的行 ID 列表。
我将该列表提供给 wp post 命令，在四核服务器上，每行耗时约 500 毫秒。如果我一次指定超过 20 行左右，Discourse 会……???……但之后就不会再生成链接了。因此，我每次发送 20 条，并设置 30 秒的延迟，利用这段时间处理其他项目。
所以，这个答案确实是个“黑客”式的变通方案，但对我而言（当时尚未看到 @angus 的回答），这是最直接的途径。