Estamos agregando la capacidad para que los usuarios ajusten su zona horaria en Wordpress para que su propia actividad en nuestro sitio se muestre en la hora local. Mientras hacemos esto, pensamos que también podríamos hacer que esa configuración se traslade al foro, para que no tengan que hacer la misma configuración dos veces. Actualmente, los usuarios en Discourse establecen su propia ubicación y zona horaria en preferencias/perfil, por lo que nos gustaría anular eso si es posible.
Parece haber una configuración de DiscourseConnect en “site_settings/category/login” llamada “discourse connect overrides location”. ¿Es esto solo para el campo “location”, o también se encarga de la zona horaria? Cuando esta casilla está marcada, ¿de dónde extrae DiscourseConnect esta información en la base de datos de WP?
es decir, si implementamos una configuración similar propia, queremos asegurarnos de almacenarla en el lugar correcto para que fluya correctamente a través de DiscourseConnect cuando activemos la opción “location”.
Después de investigar un poco más, supongo que marcar la opción “anular ubicación” en DiscourseConnect no toma la configuración de zona horaria de Wordpress, y que si queremos eso, la mejor manera sería configurarla a través de la API cada vez que el usuario edite esa información. Avísame si eso es correcto.
Sin embargo, todavía no estoy seguro de dónde proviene la “ubicación” del lado de WP, o incluso si se está transfiriendo. Por ejemplo, no veo un token de “ubicación” en el “último payload” de mi usuario. Pero sí veo avatar, biografía, nombre de usuario, id_externo, etc. Notablemente, la biografía se está transfiriendo incluso cuando no tenemos activada la opción “anular biografía”, ¿así que presumiblemente la “ubicación” también debería transferirse?
Si tienes un segundo @simon, creo que tú eres el mago de los plugins. Avísame si tienes alguna idea. ¡Gracias!
Hola @troygrady, disculpa la lentitud en la respuesta (atiendo preguntas sobre el plugin WP Discourse). Abordaré la configuración de zona horaria y ubicación por separado (no están conectadas).
Zona horaria
¿Podrías aclarar si quieres que la actividad del usuario se muestre en su hora local? Si es así, a diferencia de Wordpress, esa es actualmente la configuración predeterminada en Discourse (sin usar DiscourseConnect), y se actualizará automáticamente si el usuario no la ha establecido. Por ejemplo, recientemente pasé de la zona horaria Australia/Perth a Europe/Oslo. No he tocado la configuración de zona horaria en mi perfil aquí en meta, y ahora dice
Puedes sincronizar una ubicación establecida en un perfil de usuario de Wordpress con el campo de ubicación en el perfil del usuario en Discourse. No se sincroniza por defecto, ya que no existe un campo estándar en Wordpress que sea equivalente al campo de ubicación en Discourse. Necesitas agregar algo de código aquí. En el archivo functions.php de tu tema o en otro lugar donde puedas agregar código, necesitas agregar algo como lo siguiente, la parte clave usando el filtro wpdc_sso_params.
Ten en cuenta que deberás sustituir ‘user_location_meta’ por el campo meta de usuario que se esté utilizando para almacenar la ubicación del usuario en tu instancia de Wordpress (es decir, el campo que esté utilizando el plugin que estés usando para agregar ubicaciones de usuario a Wordpress).
También ten en cuenta que el campo de ubicación de Discourse es solo un campo de “cadena”, lo que significa que mostrará literalmente lo que se ingrese en él. No tiene ningún efecto en la zona horaria del usuario y no es una geolocalización (es decir, no está conectado con mapeo de ninguna manera).
¡Disculpa la confusión! Sí, zona horaria local, y sí, el comportamiento estándar de Discourse es genial. Como bien señalas, el problema no es Discourse, sino WP, que no tiene la capacidad de permitir a los usuarios ver el sitio en su zona horaria local. Esto es lo que queremos añadir. Si dejamos que el usuario establezca su zona horaria, entonces pensé que también deberíamos tener esa configuración para anular la configuración de Discourse para que estén sincronizados. Esto es lo que quería saber si DiscourseConnect lo proporciona. Parece que no.
Lo que no me di cuenta es que la configuración de Discourse es automática. Si ese es el caso, podríamos dejarlo como está. Es decir, implementar la zona horaria local en WP y no hacer que ese valor anule el valor de Discourse. Sí, podrían desincronizarse, pero eso podría no ser un problema para la mayoría de los usuarios.
Perfecto, esta es la pieza de información que faltaba: no sabía de dónde se suponía que DiscourseConnect debía obtener los datos de ubicación del lado de WP. Implementamos nuestro propio campo de ubicación manualmente, en usermeta, por lo que podemos extraer el valor de allí usando el hook wpdc_sso_params.
Soy denso, así que probablemente lo pasé por alto. ¿Hay alguna documentación para wpdc_sso_params en alguna parte? Encontré este hilo, que parece cubrirlo por ahora:
No, no puedes establecer zonas horarias a través de DiscourseConnect, y te recomendaría que tampoco intentes hacerlo, ya que la portabilidad de zonas horarias multiplataforma/estándar es un campo minado (hay varias listas “estándar” de zonas horarias con ligeras diferencias).
No de forma estructurada. Estoy en proceso de renovar toda la documentación de WP Discourse y publicaré una lista completa de acciones y filtros
Sobre el tema de wpdc_sso_params, nos gustaría incluir un enlace a la página de inicio de la plataforma del usuario y mostrarlo en su tarjeta. Parece que puedo configurarlo como un campo personalizado y luego pasarlo a través de un hook similar. Pero quiero que sea para nuestro uso interno, es decir, en realidad no quiero que aparezca como algo que el usuario pueda editar. Dado que controlamos todos los registros en Wordpress y la cuenta del foro se maneja automáticamente, ¿eso resolvería ese problema? Es decir, creamos el campo personalizado, lo configuramos como no editable después de la creación y luego simplemente lo actualizamos a través de sso a partir de entonces. ¿El usuario nunca vería un cuadro de edición en ningún lado?
Tener un campo personalizado de WP que contenga la “página de inicio de la plataforma del usuario”.
Pasar el campo personalizado a Discourse usando el filtro wpdc_sso_paramscomo se describe aquí.
Mostrar el campo personalizado de Discourse en la tarjeta de usuario y no permitir que el usuario lo edite en su perfil de Discourse (dejando “Editable después del registro” sin marcar).
Si eso es correcto, debería funcionar, asumiendo que no tienes ningún cuadro de edición para el campo personalizado de WP en WordPress.
Solo una nota: el personal siempre puede editar los campos de usuario (es decir, los campos personalizados), incluso si no seleccionas “Editable después del registro”. Para ver esto en acción, necesitarás probarlo con una cuenta que no sea de personal.
El truco es que los campos de usuario personalizados siempre aparecen como editables en el formulario de registro de usuarios de Discourse, incluso si nunca pretendes que los usuarios tengan acceso a ellos. Nunca queremos que los usuarios editen la URL de su página de inicio de plataforma, ya que esta es generada automáticamente por el sistema. Sin embargo, dado que nuestros usuarios nunca ven un formulario de registro de Discourse, esto puede ser irrelevante.
Dicho de otra manera, ¿hay alguna forma de crear campos personalizados que sean solo para uso interno, es decir, que nunca aparezcan en ningún tipo de formulario editable por el usuario en Discourse? Me imagino que hay muchos usos potenciales para esto en términos de integrar datos de WP u otras plataformas externas en las visualizaciones de Discourse.
Correcto. No verán el formulario de inicio de sesión.
Sí, pero no aparecerán automáticamente en la tarjeta de usuario, que es donde quieres que se muestren los datos, ¿verdad? Sin embargo, si eso es lo que quieres, puedes añadir cualquier campo arbitrario en el filtro wpdc_sso_params, por ejemplo:
Esto se almacenará en Discourse en la tabla de la base de datos user_custom_fields, pero no será visible en ningún sitio. Puedes consultarlo utilizando el Plugin Data Explorer.
Bien, nos gustaría mostrar campos arbitrarios en la tarjeta de usuario, generados por WP, relacionados con la cuenta del usuario en el sitio principal, como la URL de su página de inicio y, potencialmente, otros campos también. Nunca están destinados a ser proporcionados por el usuario, ni siquiera durante la creación de la cuenta. Solo están destinados a ser mostrados al usuario. En nuestro caso, parece que un campo “usuario” personalizado es el mejor enfoque, ya que ya incluye opciones de visualización para el perfil y la tarjeta. Y el usuario nunca ve un formulario de registro de todos modos.
El caso límite sería si no estuvieras usando SSO: el usuario vería esos campos en el formulario de registro, aunque no estén destinados a completarlos. Supongo que la solución alternativa sería ocultarlos con CSS.
De todos modos, en nuestro caso, parece que tenemos nuestra(s) solución(es) aquí. ¡Gracias!
