¿Sincronización bidireccional entre nombre de usuario de WP Discourse y nombre de usuario de Discourse?

Soporte WordPress
1

Recientemente, mi equipo y yo hemos estado trabajando en una función que permite editar el nombre de usuario de Discourse de un usuario desde WordPress con el plugin WP Discourse instalado y nuestro sitio de WordPress configurado como proveedor de SSO para Discourse. Actualmente hemos tenido cierto éxito utilizando la API de Discourse, donde tenemos un campo meta personalizado en WordPress que, cuando se actualiza, llama a la instancia de Discourse de nuestro sitio con una solicitud PUT para actualizar el nombre de usuario del usuario (similar a una solución propuesta aquí: How does one change a username via the API?)

Sin embargo, existe una opción existente dentro de WP Discourse como se muestra aquí:

Screen Shot 2022-03-03 at 4.32.35 PM
Screen Shot 2022-03-03 at 4.32.35 PM1544×168 26.5 KB

que permite a los usuarios de WordPress editar su “nombre de usuario de Discourse” a través de este campo en su página de perfil de WordPress:

Screen Shot 2022-03-03 at 4.39.58 PM
Screen Shot 2022-03-03 at 4.39.58 PM2134×172 22.6 KB

pero este campo solo se utiliza para publicar (de WP a Discourse) y en realidad no actualiza el nombre de usuario del usuario en Discourse. Se sincroniza cuando un usuario cambia su nombre de usuario en Discourse, pero no se sincroniza de WordPress a Discourse cuando se cambia.

Mi pregunta es, ¿se implementará este tipo de sincronización bidireccional en algún momento? ¿Por qué existe la opción de permitir a los usuarios cambiar este campo de nombre de usuario si no se sincroniza de WordPress a Discourse? Mi equipo también estaría interesado en contribuir con esta función si no es algo que ya esté en proceso. Nuestro sitio necesita esta funcionalidad y creemos que sería útil para todos los sitios de WP Discourse. ¡Por favor, háganmelo saber!

@angus @simon ya que ambos están muy involucrados en WP Discourse y nos ayudaron con nuestros problemas de SSO, ¡creo que debería dirigir esta pregunta a ustedes!

3 Me gusta
2

He movido esto a la categoría Support > WordPress, porque la categoría Feature está pensada para las características de Discourse.

El campo “Discourse Username Editable” en el plugin de WordPress puede tener un nombre poco claro. La redacción de la configuración definitivamente necesita ser actualizada para dejar claro cuál es su propósito. Cuando la configuración “Discourse Username Editable” está habilitada, los usuarios en el sitio de WordPress pueden establecer su nombre de usuario de Discourse en su página de perfil de WordPress. Si esa configuración no está habilitada, solo un administrador en el sitio de WordPress puede establecer el nombre de usuario de Discourse del usuario. El nombre de usuario de Discourse solo es utilizado por el plugin para publicar entradas de WordPress en Discourse.

Cuando se utiliza DiscourseConnect entre WordPress y Discourse, el nombre de usuario de Discourse del usuario se establece inicialmente a partir de su nombre de usuario de WordPress. Si la configuración auth_overrides_username está habilitada en el sitio de Discourse, el nombre de usuario en Discourse solo se puede establecer desde WordPress. Si la configuración auth overrides username no está habilitada en Discourse, los usuarios podrían editar su nombre de usuario en Discourse, por lo que los nombres de usuario podrían estar desincronizados entre los dos sistemas.

En cuanto al campo “Discourse Username”, idealmente, este campo siempre se establecería en segundo plano basándose en el nombre de usuario de Discourse. Ha pasado un tiempo desde que miré el código relacionado por última vez, pero creo que el campo “Discourse Username” se completa automáticamente si el sitio de WordPress se utiliza como proveedor de SSO para Discourse y la opción “Crear o sincronizar usuarios de Discourse al iniciar sesión” está habilitada en la pestaña de opciones del Proveedor de DiscourseConnect en WordPress. El campo “Discourse Username” también se establece automáticamente si Discourse se utiliza como proveedor de SSO para WordPress (con la configuración del Cliente de DiscourseConnect).

Idealmente, el campo “Discourse Username” siempre se establecería automáticamente cuando WordPress sea el proveedor de SSO para Discourse, independientemente de si la opción “Crear o sincronizar usuarios de Discourse al iniciar sesión” está habilitada o no en Discourse. No creo que se pueda hacer nada para el caso en que no se esté utilizando DiscourseConnect entre los dos sitios, pero @angus podría tener ideas al respecto.

Por defecto, WordPress no permite a los usuarios cambiar sus nombres de usuario, por lo que no hemos tenido muchas preguntas sobre esto. Si desea asegurarse de que los nombres de usuario se mantengan sincronizados entre WordPress y Discourse, asegúrese de habilitar la configuración auth_overrides_username en Discourse. También puede que desee habilitar la opción “Crear o sincronizar usuarios de Discourse al iniciar sesión” en WordPress. Con esa opción habilitada, los usuarios se actualizarán en Discourse cada vez que inicien sesión en su sitio de WordPress. Si esa opción no está habilitada, los usuarios solo se actualizarán en Discourse cuando cierren sesión en Discourse y vuelvan a iniciar sesión con DiscourseConnect.

3 Me gusta
3

Gracias por la respuesta @simon y la explicación de la función existente.

Nuestro sitio puede ser un caso especial, porque no queremos sincronizar el nombre de usuario de WordPress del usuario con Discourse precisamente porque WordPress no permite a los usuarios cambiar sus nombres de usuario por defecto. Y no queremos instalar un plugin que añada esta funcionalidad de edición de nombres de usuario de WP debido a la inestabilidad que podría crear.

Pero dado que los nombres de usuario son editables en Discourse, creo que tendría sentido extender esta funcionalidad a WordPress a través del plugin WP Discourse. Este campo parece el lugar perfecto para hacerlo, pero entiendo que podría entrar en conflicto con el nombre de usuario de WP, ya que este nunca cambiaría por defecto. Entonces, ¿entiendo que esto no es algo que usted quiera que aportemos al plugin?

1 me gusta
4

Además, permitir a los usuarios editar su nombre de usuario en el foro es un requisito importante para nosotros. Ya tenemos Discourse configurado para permitir esto, pero la mayoría de nuestros usuarios no cambian su nombre de usuario de Discourse porque está oculto dentro de la configuración de Discourse. Queremos que esté a la vista en su página de perfil en nuestro sitio de WordPress, junto con su otra información como nombre, avatar, etc.

1 me gusta
5

Algunas preguntas y algunas notas

Sin embargo, serán los mismos en los nuevos registros, ya que estás utilizando DiscourseConnect. Supongo que estás de acuerdo con eso, y solo te preocupa la sincronización en sí (es decir, después de la creación de la cuenta).

¿Cómo imaginas el caso en que un usuario crea una cuenta de Wordpress y aún no ha iniciado sesión en Discourse? No existirá ninguna cuenta de Discourse. En ese caso, el campo Nombre de usuario de Discourse no sería editable.

Tenga en cuenta que la webhook “Actualizar datos de usuario” (ver “Webhooks” en la configuración de WP Discourse) actualizará el Nombre de usuario de Discourse en Wordpress cuando se cambie en Discourse. Esa es una parte de la sincronización bidireccional que estás imaginando.

Entonces, específicamente, lo que buscas es que el plugin WP Discourse actualice el nombre de usuario del usuario en Discourse cuando cambie, ¿verdad?

Ahora, ese campo es utilizado por diferentes personas para diferentes propósitos. Algunas personas quieren poder editar ese campo sin actualizar el nombre de usuario del usuario de Discourse asociado con la cuenta que usan con DiscourseConnect.

Sin embargo, hay una solución relativamente sencilla. Podríamos simplemente agregar una acción en algún lugar alrededor de aquí para que puedas usar una solicitud PUT a Discourse para actualizar el nombre de usuario en Discourse, es decir, como lo estás haciendo ahora. Simplemente agregaría que la forma fácil de hacerlo es usar el método abstraído discourse_request en las Utilidades del Plugin de WP, es decir,

use WPDiscourse\\Utilities\\Utilities as DiscourseUtilities;
$path = ''
$args =  array(
);
$response = DiscourseUtilities::discourse_request( $path, $args );

Usando tanto la webhook como la devolución de llamada de acción, tendrías una sincronización bidireccional de la manera que estás imaginando, asumiendo que has tenido en cuenta las dos preguntas que planteé anteriormente.

Estaré encantado de revisar y fusionar una PR con una acción adicional en esa línea.

4 Me gusta
6

En realidad, estamos anulando este comportamiento con el hook del filtro wpdc_sso_params porque nuestro sistema SSO integra Firebase y el nombre de usuario de WP de todos por defecto es su UID de Firebase, por lo que estamos cambiando el valor predeterminado de Discourse a memberXXX (con XXX siendo un número). De hecho, también queremos cambiar este valor predeterminado a Nombre_Apellido del usuario en algún momento. Pero sí, nuestra principal preocupación es que los usuarios puedan cambiar fácilmente su nombre de usuario a través de su página de perfil en nuestro sitio de Wordpress.

En este caso, creo que podemos almacenar el campo del nombre de usuario y hacer que se sincronice cuando se crea la cuenta (a través del hook del filtro wpdc_sso_params en el primer SSO), o podríamos forzar la creación de una cuenta de Discourse para cada miembro cuando se registran en nuestro sitio de Wordpress a través de la API de Discourse. La segunda opción sería probablemente más ventajosa porque sabríamos que todos tienen una cuenta de Discourse y, por lo tanto, habría menos casos especiales de algunos usuarios que tienen cuentas y otros no. Pero realmente buscamos una experiencia fluida, por lo que queremos que este nombre de usuario sea lo que el usuario piensa como su nombre de usuario para toda nuestra plataforma. Queremos que siempre sea editable y, en el futuro, probablemente lo usaremos para más cosas que solo Discourse (es decir, en tablas de clasificación, etc.).

¡Sí, esto es exactamente lo que necesitamos!

¡Entendido! Gracias por esta dirección, mi equipo y yo trabajaremos en probar esto con nuestra implementación primero y pronto haremos un PR.

2 Me gusta