DiscourseConnectとユーザーのタイムゾーン/場所

サポート WordPress
1

こんにちは！

WordPressでユーザーがタイムゾーンを調整できるようにし、サイトでのアクティビティがローカルタイムで表示されるようにします。この作業を行うにあたり、フォーラムにもその設定が反映されるようにすれば、ユーザーは同じ設定を2回行う必要がなくなると考えました。現在、Discourseのユーザーは、[設定/プロフィール]の下で自身の場所とタイムゾーンを設定していますが、可能であればこれを上書きしたいと考えています。

「サイト設定/カテゴリ/ログイン」の下に、「DiscourseConnectが場所を上書きする」というDiscourseConnectの設定があるようです。これは「場所」フィールドのみを対象としていますか、それともタイムゾーンも処理しますか？このボックスがチェックされている場合、DiscourseConnectはこの情報をWPデータベースのどこから取得していますか？

つまり、独自の同様の設定を実装する場合、それを適切な場所に保存して、「場所」オプションをオンにしたときにDiscourseConnect経由で正しくフローするようにしたいと考えています。

ありがとうございます！

「いいね！」 3
2

さらに調べてみた結果、「DiscourseConnect」の「overrides location」オプションはWordPressのタイムゾーン設定を考慮していないのではないかと推測しています。もしそれを実現したいのであれば、ユーザーがその情報を編集するたびにAPI経由で設定するのが最善の方法でしょう。それが正しいかどうか教えていただけますか。

しかし、WordPress側で「location」がどこから来ているのか、あるいはそもそも送られてきているのかどうか、まだ確信が持てません。例えば、私のユーザーの「last payload」には「location」トークンが見当たりません。しかし、avatar、bio、username、external_idなどは見えています。特に、「override bio」が有効になっていないにもかかわらずbioが送られてきているので、おそらく「location」も送られてくるはずですよね？

もしよろしければ、@simonさん、あなたはプラグインの魔術師だと信じています。何か洞察があれば教えていただけますでしょうか。ありがとうございます！

「いいね！」 1
3

@troygrady様、返信が遅くなり申し訳ありません（WP Discourseプラグインに関する質問に対応しています）。タイムゾーンと場所の設定は（関連性がないため）別々に説明します。

タイムゾーン

ユーザーのアクティビティがユーザー自身のローカルタイムで表示されることを意味しますか？もしそうであれば、WordPressとは異なり、これは現在Discourseのデフォルトであり（DiscourseConnectを使用せずに）、ユーザーが設定しなくても自動的に更新されます。例えば、私は最近タイムゾーンを「Australia/Perth」から「Europe/Oslo」に変更しました。ここmetaのプロファイルでタイムゾーン設定を変更していませんが、次のように表示されています。

Screenshot 2022-03-22 at 08.33.55
Screenshot 2022-03-22 at 08.33.551082×240 27.2 KB

これとは異なる動作をご希望ですか？

場所

WordPressのユーザープロファイルで設定された場所を、Discourseのユーザープロファイルの場所フィールドと同期させることができます。デフォルトでは同期されません。なぜなら、Discourseの場所フィールドに相当する標準的なWordPressのフィールドが存在しないからです。ここにコードを追加する必要があります。テーマのfunctions.phpファイルまたはコードを追加できる別の場所に、以下のようなものを追加する必要があります。wpdc_sso_paramsフィルターの使用が鍵となります。

function sync_discourse_location( $params, $user ) {
    $location = get_user_meta( $user->ID, 'user_location_meta', true );
    if ( $location  ) {
        $params['location'] = $location;
    }
    return $params;
}
add_filter( 'wpdc_sso_params', 'sync_discourse_location', 10, 2 );

'user_location_meta'は、WordPressインスタンスでユーザーの場所を保存するために使用されているユーザーメタフィールド（つまり、ユーザーの場所をWordPressに追加するために使用しているプラグインによって使用されているフィールド）に置き換える必要があることに注意してください。

また、Discourseの場所フィールドは単なる「文字列」フィールドであり、入力されたものをそのまま表示するだけであることにも注意してください。ユーザーのタイムゾーンには影響せず、ジオロケーション（マッピングに関連付けられている）でもありません。

「いいね！」 1
4

アンガスさん、ありがとうございます！遅延については心配いりません。

混乱させて申し訳ありません！はい、ローカルタイムゾーンです。そして、はい、標準のDiscourseの動作は素晴らしいです。ご指摘の通り、問題はDiscourseではなく、WPがユーザーにローカルタイムゾーンでサイトを表示する機能を持っていないことです。これを追加したいのです。ユーザーがタイムゾーンを設定できるようにすれば、Discourseの設定も上書きして同期させることができると考えました。これが知りたかったことです。DiscourseConnectでそれが可能かどうか。どうやらそうではないようです。

Discourseの設定が自動であることを知りませんでした。もしそうであれば、そのままにしておくかもしれません。つまり、WPでローカルタイムゾーンを実装し、その値をDiscourseの値で上書きしないということです。はい、同期がずれる可能性はありますが、ほとんどのユーザーにとっては問題にならないかもしれません。

完璧です。これが足りなかった情報です。DiscourseConnectがWP側で場所データをどこから取得するのか分かっていませんでした。独自の場所フィールドをusermetaに手動で実装したので、wpdc_sso_paramsフックを使用してそこから値を取得できます。

私は鈍感なので、おそらく見落としていました。wpdc_sso_paramsのドキュメントはどこかにありますか？このスレッドを見つけましたが、今のところこれでカバーできそうです。

「いいね！」 2
5

いいえ、DiscourseConnect経由でタイムゾーンを設定することはできません。また、クロスプラットフォーム/標準のタイムゾーンの移植性は少々厄介なため（わずかに異なる複数の「標準」タイムゾーンリストが存在します）、試みることもお勧めしません。

構造化された形ではありません。WP Discourseのドキュメント全体をオーバーホールしており、アクションとフィルターの包括的なリストを公開する予定です :slight_smile:

「いいね！」 1
6

承知いたしました、問題ありません。

wpdc_sso_paramsの件ですが、ユーザーのプラットフォームホームページへのリンクを含め、カードに表示したいと考えています。カスタムフィールドとして設定し、同様のフック経由で渡すことができるようです。しかし、これは内部使用のみを目的としており、ユーザーが編集できるものとしては表示させたくありません。WordPressでのサインアップはすべてこちらで管理しており、フォーラムアカウントは自動的に処理されるため、これで問題は解決するでしょうか？つまり、カスタムフィールドを作成し、作成後に編集不可に設定し、その後SSO経由で更新するだけです。ユーザーは編集ボックスを一切目にすることはありませんか？

「いいね！」 1
7

確認のため、あなたがやりたいことは以下の通りでよろしいでしょうか。

  1. 「ユーザーのプラットフォームホームページ」を含むWPカスタムフィールドを用意する。
  2. カスタムフィールドをwpdc_sso_paramsフィルターを使用してDiscourseに渡す（こちらで説明されています）。
  3. Discourseのカスタムフィールドをユーザーカードに表示し、Discourseプロフィールで編集できないようにする（「サインアップ後の編集」のチェックを外す）。

これで合っていれば、WordPress自体にWPカスタムフィールドの編集ボックスがない限り、機能するはずです。

なお、スタッフは「サインアップ後の編集」を選択しなくても、常にユーザーフィールド（カスタムフィールド）を編集できることに注意してください。これを実際に確認するには、スタッフ以外のユーザーアカウントでテストする必要があります。

「いいね！」 2
8

はい、それがまさに私たちがやりたいことです。

ただし、カスタムユーザーフィールドは、ユーザーに編集可能にすることを意図していない場合でも、常にDiscourseのユーザーサインアップフォームで編集可能として表示されるようです。プラットフォームのホームページURLはシステムによって自動生成されるため、ユーザーに編集してもらいたくありません。しかし、私たちのユーザーはDiscourseのサインアップフォームを実際に見ることはないため、これは関係ないかもしれません。

別の言い方をすれば、内部専用のカスタムフィールドを作成する方法はありますか？つまり、Discourseの編集可能なフォームに表示されないフィールドです。WPやその他の外部プラットフォームのデータをDiscourseの表示に統合する上で、多くの潜在的な用途があると思われます。

「いいね！」 1
9

はい。ログインフォームは表示されません。

はい、ただし、それらはユーザーカードに自動的に表示されるわけではありません。そこにデータを表示したいのですよね？それにもかかわらず、それが望むものであれば、たとえば wpdc_sso_params フィルターに任意のフィールドを追加するだけです。

$sso_params["custom.not_a_user_field"] = "field value";

これはDiscourseの user_custom_fields データベーステーブルに保存されますが、どこにも表示されません。Data Explorer Pluginを使用してクエリできます。

「いいね！」 3
10

承知いたしました。ユーザーカードに、メインサイトのユーザーアカウントに関連するWPによって生成された任意のフィールド（ホームページURLやその他のフィールドなど）を表示したいと考えています。これらは、アカウント作成時であっても、ユーザーが入力するものではありません。表示のみを目的としています。当社のケースでは、カスタム「ユーザー」フィールドが最適であると思われます。これは、プロフィールやカードの表示オプションがすでに含まれているためです。また、ユーザーはサインアップフォームを見ることはありません。

エッジケースとしては、SSOを使用しない場合です。ユーザーは、入力する意図のないフィールドをサインアップフォームで目にすることになります。その場合の回避策はCSSで非表示にすることでしょうか？

いずれにせよ、当社のケースでは、ここで解決策が見つかったようです。ありがとうございました！

「いいね！」 2
11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.