dbwhite
(Dwight Bumgarner)
1
最近，我的团队和我一直在开发一项功能，该功能允许在安装了 WP Discourse 插件并已将我们的 WordPress 网站设置为 Discourse 的 SSO 提供商的情况下，从 WordPress 编辑用户的 Discourse 用户名。目前，我们已通过 Discourse API 取得了一些成功，我们在 WordPress 中有一个自定义元字段，当该字段更新时，它会通过 PUT 请求调用我们的网站的 Discourse 实例来更新用户的用户名（类似于此处提出的解决方案：https://meta.discourse.org/t/how-does-one-change-a-username-via-the-api/96118）。
但是，WP Discourse 中已有一个选项，如下图所示：
该选项允许 WordPress 用户通过其 WordPress 个人资料页面中的此字段来编辑其“Discourse 用户名”：
但此字段仅用于发布帖子（从 WP 到 Discourse），实际上并不会更新 Discourse 中的用户用户名。当用户在 Discourse 中更改用户名时，它会同步，但当在 WordPress 中更改时，它不会从 WordPress 同步到 Discourse。
我的问题是，这种双向同步是否会在某个时候实现？如果该选项不允许从 WordPress 同步到 Discourse，为什么还要提供允许用户更改此用户名字段的选项？如果这不是正在进行的工作，我的团队也有兴趣为此功能做出贡献。我们的网站需要此功能，并且我们认为它对所有 WP Discourse 网站都很有用。请告知！
@angus @simon 由于你们两位都深度参与 WP Discourse 并帮助我们解决了 SSO 问题，我认为我应该将这个问题直接问你们！
3 个赞
simon
2
我已将此移至 Support > WordPress 类别，因为 Feature 类别仅用于 Discourse 功能。
WordPress 插件中的“Discourse 用户名可编辑”字段可能命名不当。该设置的文案肯定需要更新，以清楚地说明该设置的用途。启用“Discourse 用户名可编辑”设置后，WordPress 网站上的用户可以在其 WordPress 个人资料页面上设置其 Discourse 用户名。如果未启用该设置，则只有 WordPress 网站上的管理员可以设置用户的 Discourse 用户名。Discourse 用户名仅由插件用于将帖子从 WordPress 发布到 Discourse。
当 WordPress 和 Discourse 之间使用 DiscourseConnect 时，用户的 Discourse 用户名最初是从其 WordPress 用户名设置的。如果 Discourse 网站上启用了 auth_overrides_username 设置，则只能从 WordPress 设置 Discourse 上的用户名。如果 Discourse 上未启用 auth overrides username 设置，用户可以在 Discourse 上编辑其用户名，从而导致两个系统之间的用户名不同步。
在 Discourse 用户名字段方面，理想情况下，该字段应始终根据 Discourse 用户名在后台设置。我上次查看相关代码已经有一段时间了，但我相信，如果 WordPress 网站用作 Discourse 的 SSO 提供商，并且在 WordPress 上的 DiscourseConnect 提供商选项卡中启用了“登录时创建或同步 Discourse 用户”选项，则 Discourse 用户名字段会自动填充。如果 Discourse 用作 WordPress 的 SSO 提供商（使用 DiscourseConnect 客户端设置），Discourse 用户名字段也会自动设置。
理想情况下，当 WordPress 是 Discourse 的 SSO 提供商时，Discourse 用户名字段应始终自动设置，无论是否在 Discourse 上启用了“登录时创建或同步 Discourse 用户”选项。我认为在两个站点之间未使用 DiscourseConnect 的情况下无法采取任何措施，但 @angus 可能对此有想法。
默认情况下，WordPress 不允许用户更改其用户名，因此我们很少收到有关此问题的咨询。如果您想确保 WordPress 和 Discourse 之间的用户名保持同步，请确保在 Discourse 上启用 auth_overrides_username 设置。您可能还想在 WordPress 上启用“登录时创建或同步 Discourse 用户”选项。启用该选项后，用户每次登录您的 WordPress 网站时都会在 Discourse 上更新。如果未启用该选项，用户仅在注销 Discourse，然后使用 DiscourseConnect 重新登录时才会在 Discourse 上更新。
3 个赞
dbwhite
(Dwight Bumgarner)
3
感谢您的回复@simon 和对现有功能的解释。
我们的网站可能有点特殊，因为我们不希望用户的 Wordpress 用户名与 Discourse 同步，原因正是 Wordpress 默认不允许用户更改其用户名。而且我们不希望安装一个添加此 WP 用户名编辑功能的插件，因为这可能会带来不稳定性。
但是，由于 Discourse 中的用户名是可编辑的，我认为通过 WP Discourse 插件将此功能扩展到 Wordpress 会很有意义。这个字段似乎是实现这一目标的理想位置，但我明白这可能会与 WP 用户名发生冲突，因为默认情况下 WP 用户名永远不会改变。所以，我理解您不希望我们为此插件做出贡献，是吗？
1 个赞
dbwhite
(Dwight Bumgarner)
4
此外，允许用户在论坛中编辑其用户名对我们来说是一项主要要求。我们已经设置了 Discourse 以允许这样做，但我们的大多数用户不更改其 Discourse 用户名，因为它隐藏在 Discourse 设置中。我们希望它在我们的 WordPress 网站的个人资料页面上显而易见，以及他们的姓名、头像等其他信息。
1 个赞
angus
(Angus McLeod)
5
一些问题和一些说明
但是，当您使用 DiscourseConnect 进行新注册时，它们将是相同的。我假设您对此没问题，并且您只关心同步本身（即，在创建帐户之后）？
您设想用户创建 Wordpress 帐户但尚未登录 Discourse 的情况是如何处理的？在这种情况下，将不存在 Discourse 帐户。在这种情况下，“Discourse 用户名”字段将不可编辑？
请注意，“更新用户数据”Webhook（请参阅 WP Discourse 设置中的“Webhook”）将在 Discourse 中更改用户名时，在 Wordpress 中更新 Discourse 用户名。这是您设想的双向同步的一部分。
那么，您具体想要的是 WP Discourse 插件在用户更改其 Discourse 用户名时更新该用户名，对吗？
现在，该字段被不同的人用于不同的目的。有些人希望能够编辑该字段，而不更新与他们使用 DiscourseConnect 的帐户相关联的 Discourse 用户的用户名。
但是，有一个相对简单的解决方案。我们可以在此处附近添加一个 action，以便您可以使用 PUT 请求更新 Discourse 上的用户名，即，就像您现在所做的那样。我只是补充一点，最简单的方法是使用 WP 插件的 Utilities 中抽象的 discourse_request 方法，即：
use WPDiscourse\\Utilities\\Utilities as DiscourseUtilities;
$path = ''
$args = array(
);
$response = DiscourseUtilities::discourse_request( $path, $args );
通过使用 Webhook 和 action 回调，您将拥有设想中的双向同步，前提是您已考虑了我上面提出的两个问题。
我很乐意审查并合并一个包含类似附加 action 的 PR。
4 个赞
dbwhite
(Dwight Bumgarner)
6
我们实际上正在使用 wpdc_sso_params 过滤器钩来覆盖此行为，因为我们的 SSO 系统集成了 Firebase，并且每个人的 WP 用户名默认为他们的 Firebase UID，因此我们将 Discourse 的默认值更改为 memberXXX（XXX 是一个数字）。我们实际上希望在某个时候也将此默认值更改为用户的 Firstname_Lastname。但是的，我们的主要关注点是用户能够通过我们 WordPress 网站内的个人资料页面轻松更改他们的用户名。
在这种情况下，我认为我们可以存储用户名字段，并在账户创建时（通过首次 SSO 上的 wpdc_sso_params 过滤器钩）进行同步，或者我们可以通过 Discourse API 为每个会员在 WordPress 网站上注册时强制创建一个 Discourse 账户。第二种选择可能更有利，因为我们知道每个人都有一个 Discourse 账户，因此特殊情况会更少，即有些用户有账户而有些用户没有。但我们确实追求无缝的体验，所以我们希望这个用户名成为用户在我们整个平台上的用户名。我们希望它始终可编辑，并且将来我们可能会将其用于比 Discourse 更多的地方（例如，排行榜等）。
是的，这正是我们需要的！
明白了！感谢您的指导，我和我的团队将首先在我们的实现中进行测试，并很快提交一个 PR！
2 个赞
