这似乎仅在电子邮件地址被更改时发生。例如：
https://forum.{mySite}.com/u/{user}/preferences/email
- 用户成功收到确认邮件
- 用户点击链接
- 用户收到错误：“哎呀！页面未找到或为私有”
确认邮件链接模板：
%{base_url}/u/authorize-email/%{email_token}
实际确认邮件链接：
https://forum.{mySite}.com/u/authorize-email/{someHash}
你能复现这个问题吗 @tshenry？
我们这周也遇到了同样的问题，正如上面描述的那样。
您很可能在我们更改链接之前已经自定义了该邮件模板。
请前往 /admin/customize/email_templates/user_notifications.confirm_new_email，确保其中的链接格式如下：
%{base_url}/u/confirm-new-email/%{email_token}
而不是：
%{base_url}/u/authorize-email/%{email_token}
也许终究还是应该添加一个迁移方案。这个问题已经多次出现了。
cc @sam
https://review.discourse.org/t/feature-improve-email-change-workflow-pr-8377/7150/4
那个坏掉的链接算是解决了……勉强算吧；现在它只是把用户重定向到登录页面。
虽然很高兴大家能注意到这个问题，确保用户能够修改邮箱，但为什么管理员在后台面板中无法直接编辑邮箱呢？唯一的方法似乎是模拟登录 >> 个人资料 >> 修改邮箱？我看到的确实是这样——这真的是正确的做法吗？
我可以删除账户并模拟登录，但却不能直接修改邮箱？这听起来有点不合逻辑~
%{base_url}/u/confirm-new-email/%{email_token}
我的链接看起来就是这样，但它仍然会把用户导向一个“哎呀”错误页面。您的意思是应该反过来吗？
对我来说，%{base_url}/u/confirm-new-email/%{email_token} 会将用户重定向到登录页面，而未能激活账户。另一个则是“哎呀”页面。
这有点奇怪，但：
它原本是：
%{base_url}/u/confirm-new-email/%{email_token}，结果报错了
我把它改成了：
%{email_token}/u/authorize-email/%{base_url}，结果还是报错
我又手动改回：
%{base_url}/u/confirm-new-email/%{email_token}（不是通过重置）
现在它居然能用了！
编辑：哦，现在又不行了。
我想再推迟一段时间处理这个问题。
那么，提供一个向后兼容（已弃用）的镜像链接呢？或者为几个版本提供一个替换脚本？下一个版本能否将旧的 %{} 替换为新的 %{}？如果已经迁移，则不会发生任何变化。
但无论如何——我的问题仍未解决……至少看起来是这样：它只是将用户重定向到登录页面，而没有激活。
https://forum.{mySite}.com/u/confirm-new-email/{someHash}
^ 这是正确的吗？对方坚持说他们使用了无痕模式，并展示了登录页面的截图。经检查，我发现旧邮箱地址在管理员后台仍然显示。
我不太明白，为什么不直接删除所有相关的语言区域自定义设置，然后从头开始呢？
因为像我和其他人一样——他们根本不知道这件事发生了。这可不是那种带闪烁灯光的“点击更新”按钮，在提醒我们要更改邮件模板。
我确实照做了，但是：
- 如果你没有特意发现这个问题、在 Google 上搜索、找到这篇帖子并手动解决，你甚至根本不会知道发生了这种事。
- 这个过程一点也不直观（而且还要假设用户会“神奇地”知道发生了这种情况），这与 Discourse 一贯的风格不符。
- 准确性下降且过程繁琐——如果你搞错了模板，就需要一封模拟邮件来测试。如果不找到这篇帖子，你甚至不知道应该改成什么。
说实话，我在这里已经有账号了，却仍然对此一无所知，不得不费力寻找解决办法。在我看来，与其他任何更新相比，Discourse 的管理员体验都不可接受（这是我经历过的第一个“故意破坏性”的更新）。我并不是在为自己请求什么，因为我已经按你说的解决了问题——我是为了其他人。
谁知道这个问题在我的论坛上存在了多久？我想知道我们因为不知道某个更新带来了破坏性的模板变更而流失了多少新用户？我不可能是唯一一个遇到这种情况的人。
只是想跟进一下此事。
我从未自定义过它。它包含您建议的 %{base_url}/u/confirm-new-email/%{email_token}，但在实际邮件中，链接里却是 /authorize-email/。所以我猜在 Web 管理面板和 Discourse 引擎深处某个配置文件之间出了问题。当前运行版本为 2.5.0.beta6。 编辑：更奇怪的是：当管理员更改电子邮件地址时，发给旧地址的确认邮件使用的是 %{base_url}/u/confirm-new-email/%{email_token}，而发给新地址的确认邮件却使用的是 %{base_url}/u/authorize-email/%{email_token}。
@Willemb2 在我们的实例中发现，该问题仅出现在界面语言设置为特定语言的用户身上。因此，无论我尝试多少次将界面切换为我使用的语言，对说法语的用户都没有任何影响。我不得不将自己的界面语言设置为法语，之后突然就能自定义法语版本了，从那以后我们就再也没遇到过这个问题。
@gh_irina 我检查了这个问题，但默认语言（在我们的案例中是荷兰语）的用户也会出现这种情况。
哦，那真烦人。很抱歉。
我在一个我参与的论坛上遇到了这个问题。我通过手动调整链接解决了它。对于这些重大更改，为什么不包含一个旧链接的捕获器来提醒管理员呢？