В файле Utilities есть вспомогательная функция для этого:
DiscourseUtilities::sync_sso_record( $sso_params );
Вчера я опубликовал пример того, как её использовать: I cannot add user to the discouse forum from a wordpress website when user added in a membership - #10 by simon. Самая сложная часть — создать массив для аргумента sso_params. Этот массив должен содержать поле external_id. Оно устанавливается в значение ID пользователя WordPress:
$sso_params = array(
'external_id' => $user_id,
);
В полезную нагрузку можно включить любые поля из этого списка: discourse/lib/discourse_connect_base.rb at 8f52fd1051e20fdff41321c5cff99fda05af86c1 · discourse/discourse · GitHub. Обратите внимание на массив BOOLS, который показан сразу под списком ACCESSORS, на который я дал ссылку. Он указывает, какие из возможных параметров являются булевыми (true/false). При отправке запросов из WordPress любые булевы поля должны задаваться строками 'true' или 'false', а не значениями PHP true или false.
Для обновления аватара установите поле avatar_url в массиве $sso_params, а также установите поле avatar_force_update в значение 'true'.
Существует поле bio, которое можно использовать для установки биографии.
Плагин WP Discourse уже устанавливает поля bio и avatar_url. У него также есть настройка «Принудительное обновление аватара» в настройках SSO. Проблема может заключаться в том, что эти настройки обновляются только тогда, когда пользователь входит в Discourse через сайт WordPress. Функция sync_sso_record обновляет поля немедленно, без необходимости входа пользователя в Discourse.
Кроме того, если вы обнаружите, что биографии пользователей не устанавливаются в Discourse, возможно, они не задаются на вашем сайте WordPress, откуда плагин ожидает их получить: wp-discourse/lib/plugin-utilities.php at 99325e15190f3a705284dbf582f1c4b2c0b21492 · discourse/wp-discourse · GitHub. Если в WooCommerce используется другое поле для биографии, вы можете получить доступ к этому полю и использовать его при вызове sync_sso_record.