这里发生的情况是这样的：
-
有些人在他们的
app.yml文件中有一个非常旧版本的问答插件，其存储库 URL 中包含我的个人 GitHub 用户名。 -
我多年前已将 QnA 插件转移到
paviliondev。GitHub 会在存储库转移时重定向 URL，因此包含我个人用户名的旧 URL 仍然有效。 -
多年后，Pavilion 将 Question Answer 插件转移到了 Discourse。Discourse 最初保留了名称
discourse-question-answer。 -
几个月前，我创建了我自己的插件分支，托管在
discourse中，当时它仍然被称为discourse-question-answer。 -
那些拥有指向包含我的个人 GitHub 帐户的 QnA 插件的非常旧链接的人，现在正在克隆托管在
discourse中、经过显著更新的discourse-question-answer的新分支。换句话说，一个非常旧的链接现在指向了一个新插件的分支。尽管已经过去了这么多年，我本应该预料到这一点，对此我感到抱歉。我已经删除了那个分支。 -
Discourse 将
discourse-question-answer的名称更改为discourse-upvotes。这个名称更改对您的情况 @Jaap-Jan_Swijnenburg 没有实质性影响，但这就是为什么您现在（意外地）克隆该存储库分支的原因。 -
discourse/discourse-upvotes（以前是discourse-question-answer）中的迁移假定post_custom_fields中的value列是 JSON 类型安全的。 -
该插件在
angusmcleod/discourse-question-answer（多年前）时创建的旧数据，并未被discourse/discourse中的HasCustomFields关联保存为有效的 JSON。我猜测，这些数据可能是在添加 JSON 类型检查 4 年前 之前添加的（在边缘情况下，注册为 JSON 的自定义字段中仍然可能出现无效 JSON）。
因此
- 当那些在
app.yml中拥有（过时多年的）angusmcleod/discourse-question-answerURL 的人在更新他们的 Discourse 时，会克隆插件的新版本中的迁移，迁移运行，并可能产生此错误。
有几种解决方案：
-
@Jaap-Jan_Swijnen元，在您的情况下，您只需要删除指向我旧 QnA 插件的引用，就可以重建您的站点。就是这样；仅此而已。看起来您已经做到了
-
可以更新
discourse/discourse-upvotes插件的迁移，以处理post_custom_fields中value列中的非 JSON 值。
我想指出的是，2 也可以处理那些确实想从旧版 QnA 插件切换到 discourse-upvotes 的用户的情况。在这种情况下，迁移将运行，如果 post_custom_fields 的 value 列中的任何条目不是有效的 JSON，迁移将失败。