DiscourseConnect и часовой пояс / местоположение пользователя

[troygrady]

Привет!

Мы добавляем возможность для пользователей изменять свой часовой пояс в WordPress, чтобы их активность на нашем сайте отображалась в местном времени. Поскольку мы это делаем, мы решили, что стоит также перенести этот настройку на форум, чтобы пользователям не приходилось настраивать её дважды. В настоящее время пользователи Discourse задают своё местоположение и часовой пояс в разделе «Настройки»/«Профиль», поэтому мы хотели бы, по возможности, переопределить эти значения.

Кажется, что в DiscourseConnect есть настройка под разделом «site_settings/category/login» с названием «discourse connect overrides location». Относится ли это только к полю «местоположение» или оно также затрагивает часовой пояс? Когда этот флажок установлен, откуда именно DiscourseConnect извлекает эту информацию из базы данных WordPress?

То есть, если мы реализуем аналогичную настройку, нам важно убедиться, что мы сохраняем её в правильном месте, чтобы она корректно передавалась через DiscourseConnect при включении опции «местоположение».

Спасибо!

[troygrady]

После дополнительных исследований я предполагаю, что включение опции «Переопределить местоположение» в DiscourseConnect не учитывает настройку часового пояса из WordPress, и что если нам это нужно, то лучший способ — устанавливать её через API всякий раз, когда пользователь редактирует эту информацию. Дайте знать, если я прав.

Однако я всё ещё не уверен, откуда берётся поле «location» на стороне WordPress, или даже передаётся ли оно вообще. Например, я не вижу токена «location» в «последнем полезной нагрузке» для моего пользователя. Но я вижу аватар, био, имя пользователя, external_id и так далее. Примечательно, что био передаётся, хотя у нас не включена опция «Переопределить био», поэтому, presumably, «location» тоже должно передаваться?

Если у вас есть минутка, @simon, я полагаю, что вы мастер плагинов. Дайте знать, если у вас есть какие-либо идеи. Спасибо!

[angus (Angus McLeod)]

Привет, @troygrady, извините за медленный ответ (я отвечаю на вопросы по плагину WP Discourse). Я отдельно рассмотрю настройки часового пояса и местоположения (они не связаны между собой).

Часовой пояс

@troygrady

Мы добавляем возможность для пользователей настраивать свой часовой пояс в WordPress, чтобы их собственная активность на нашем сайте отображалась в местном времени.

Можете ли вы уточнить, имеете ли вы в виду, что хотите, чтобы активность пользователей отображалась для них в их местном времени? Если да, то, в отличие от WordPress, в Discourse это сейчас установлено по умолчанию (без использования DiscourseConnect) и автоматически обновляется, если пользователь не задаст его вручную. Например, недавно я переехал из часового пояса Australia/Perth в Europe/Oslo. Я не менял настройку часового пояса в своём профиле здесь, на meta, и теперь она отображается так:

Хотите ли вы поведения, отличного от этого?

Местоположение

Вы можете синхронизировать местоположение, установленное в профиле пользователя WordPress, с полем местоположения в профиле пользователя на Discourse. По умолчанию синхронизация не работает, так как в WordPress нет стандартного поля, эквивалентного полю местоположения в Discourse. Вам нужно добавить немного кода. В файле 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 — это просто поле типа “строка”, что означает, что оно будет отображать введённое в него значение буквально. Оно не влияет на часовой пояс пользователя и не является геолокацией (то есть не связано с картами каким-либо образом).

[troygrady]

Спасибо, Энгус! И не переживай из-за задержки.

@angus

@troygrady

Мы добавляем возможность для пользователей настраивать свой часовой пояс в WordPress, чтобы их активность на нашем сайте отображалась в местном времени

Мог бы ты просто уточнить, имеешь ли ты в виду, что ты хочешь, чтобы активность пользователя отображалась для него в его местном времени? Если да, то, в отличие от WordPress, в Discourse это уже установлено по умолчанию.

Извини за путаницу! Да, местный часовой пояс, и да, стандартное поведение Discourse отлично подходит. Как ты и указал, проблема не в Discourse, а в WordPress, который не позволяет пользователям видеть сайт в их местном часовом поясе. Именно это мы хотим добавить. Если мы дадим пользователю возможность установить свой часовой пояс, то я подумал, что нам следует также сделать так, чтобы этот параметр переопределял настройку в Discourse, чтобы они были синхронизированы. Вот что я хотел узнать: предоставляет ли это DiscourseConnect. Похоже, что нет.

То, что я не учел, это то, что настройка в Discourse автоматическая. Если это так, мы, возможно, просто оставим всё как есть. То есть реализовывать местный часовой пояс в WordPress, но не позволять этому значению переопределять значение в Discourse. Да, они могут рассинхронизироваться, но для большинства пользователей это может не стать проблемой.

@angus

Вы можете синхронизировать локацию, установленную в профиле пользователя WordPress, с полем локации в профиле пользователя на Discourse. По умолчанию синхронизация не работает, так как в WordPress нет стандартного поля, эквивалентного полю локации в Discourse.

Отлично, это недостающий кусочек информации — я не знал, откуда DiscourseConnect должен получать данные о локации на стороне WordPress. Мы реализовали наше собственное поле локации вручную в usermeta, поэтому мы можем просто извлечь значение оттуда, используя хук wpdc_sso_params.

Я, наверное, был невнимателен и упустил это. Есть ли где-нибудь документация по wpdc_sso_params? Я нашел эту тему, которая, похоже, пока покрывает этот вопрос:

Map custom User Fields

You can update User Fields that you have created on Discourse via SSO. This does not require a plugin. To do this, you need to know the name that Discourse uses in the database for the custom field. The easiest way I know of to do this is by going to your Admin / Customize / User Fields page and then loading the JSON version of the page. For example https://forum.example.com/admin/customize/user_fields.json The JSON data of the page will look something like this: { user_fields: [ { id: 12, nam…

[angus (Angus McLeod)]

@troygrady

Если мы позволим пользователю устанавливать свой часовой пояс, то, по моему мнению, это настройка должна переопределять настройки Discourse, чтобы они были синхронизированы. Именно это я хотел узнать, предоставляет ли DiscourseConnect. Похоже, что нет.

Нет, вы не можете устанавливать часовые пояса через DiscourseConnect, и я бы не рекомендовал пытаться это делать, так как кроссплатформенная и стандартная переносимость часовых поясов — это своего рода минное поле (существует несколько «стандартных» списков часовых поясов с незначительными различиями).

@troygrady

Я, наверное, упёртый, поэтому, скорее всего, упустил это. Где-нибудь есть их документация по wpdc_sso_params? Я нашёл эту тему, которая, похоже, пока покрывает этот вопрос:

Нет, в структурированном виде. Я в процессе полной переработки всей документации WP Discourse и опубликую полный список действий и фильтров

[troygrady]

Понял, без проблем.

Касательно wpdc_sso_params: мы хотим добавить ссылку на домашнюю страницу платформы пользователя и отображать её на его карточке. Похоже, я могу настроить это как пользовательское поле и передать через аналогичный хук. Но мне нужно, чтобы это было для внутреннего использования, то есть я не хочу, чтобы это отображалось как редактируемое пользователем. Поскольку мы контролируем все регистрации в WordPress, а учётная запись на форуме создаётся автоматически, это может решить проблему? То есть мы создаём пользовательское поле, делаем его неизменяемым после создания, а затем обновляем его через SSO. Пользователь никогда не увидит поле для редактирования?

[angus (Angus McLeod)]

Чтобы убедиться, что я всё правильно понял, вы хотите сделать следующее:

1. Создать пользовательское поле WP, содержащее «домашнюю страницу платформы пользователя».
2. Передавать это пользовательское поле в Discourse с помощью фильтра wpdc_sso_params как описано здесь.
3. Отображать пользовательское поле Discourse на карточке пользователя и запретить пользователю редактировать его в своём профиле Discourse (оставив опцию «Редактируемо после регистрации» снятой).

Если всё верно, это должно работать, при условии, что в самом WordPress нет поля для редактирования этого пользовательского поля WP.

Просто примите во внимание, что сотрудники всегда могут редактировать пользовательские поля (то есть пользовательские поля), даже если вы не выбрали опцию «Редактируемо после регистрации». Чтобы увидеть это в действии, вам нужно протестировать это с учётной записью, не являющейся учётной записью сотрудника.

[troygrady]

Да, именно это мы и хотим сделать.

Проблема в том, что пользовательские поля всегда отображаются как редактируемые в форме регистрации пользователя на Discourse, даже если вы никогда не планировали предоставлять к ним доступ пользователям. Мы не хотим, чтобы пользователи могли редактировать URL своей домашней страницы платформы, так как он автоматически генерируется системой. Однако, поскольку наши пользователи на самом деле никогда не видят форму регистрации Discourse, это может быть неактуально.

Иными словами, существует ли способ создать пользовательские поля, предназначенные только для внутреннего использования, то есть которые никогда не будут отображаться ни в какой редактируемой пользователем форме в Discourse? Я предполагаю, что для этого есть множество потенциальных применений, например, для интеграции данных из WordPress или других внешних платформ в отображение на Discourse.

[angus (Angus McLeod)]

@troygrady

Однако, поскольку наши пользователи на самом деле никогда не видят форму регистрации Discourse, это может быть неактуально.

Верно. Они не увидят форму входа.

@troygrady

Иными словами, есть ли способ создать пользовательские поля, предназначенные только для внутреннего использования, то есть которые никогда не отображаются ни в какой форме редактирования пользователем в Discourse? Я предполагаю, что это может иметь множество потенциальных применений при интеграции данных из WP или других внешних платформ в отображение Discourse.

Да, но они не появятся автоматически на карточке пользователя, где, как я понимаю, вы хотите отобразить данные, верно? Тем не менее, если это именно то, что вам нужно, вы можете просто добавить любое произвольное поле в фильтр wpdc_sso_params, например:

$sso_params["custom.not_a_user_field"] = "значение поля";

Это будет сохранено в Discourse в таблице базы данных user_custom_fields, но нигде не будет отображаться. Вы можете запросить его с помощью плагина Data Explorer.

[troygrady]

Хорошо, мы хотели бы отображать произвольные поля на карточке пользователя, генерируемые WP, которые относятся к учётной записи пользователя на основном сайте — например, URL их домашней страницы и, возможно, другие поля. Они никогда не должны вводиться пользователем, даже при создании учётной записи. Они предназначены только для отображения пользователю. В нашем случае, похоже, лучшим решением будет использование пользовательского поля «user», поскольку оно уже включает параметры отображения для профиля и карточки. Кроме того, пользователь всё равно не видит форму регистрации.

Исключительный случай возникнет, если вы не используете SSO: пользователь увидит эти поля в форме регистрации, хотя они не предназначены для заполнения. Предполагаю, что обходным путём в этом случае будет просто скрыть их с помощью CSS?

В любом случае, для нашего случая, похоже, у нас уже есть решение(я). Спасибо!