Tengo una copia de staging de un sitio WP de unos meses. Pensé en probar cómo funciona el SSO con el foro (cerrado para registros, aún no lanzado) y luego conectarlo con el sitio de producción, que tendrá un poco más de usuarios añadidos mientras tanto. ¿Confundiría esto a Discourse? Intentaría con un puñado de usuarios de staging cómo funcionan las cosas, pero ¿qué les sucede cuando la conexión se cambia para usar el otro sitio? Sin embargo, su ID de usuario y correo electrónico de WP siguen siendo los mismos.
1 me gusta
Si el ID de usuario de WP y el correo electrónico son los mismos en sus sitios de producción y staging, puede cambiar al sitio de producción sin tener que hacer ningún cambio en el lado de Discourse.
Sería una buena idea verificar dos veces para asegurarse de que los ID de usuario sean los mismos. Recuerdo que con los sitios de staging y producción de WP Engine no había garantía de que los ID de usuario coincidieran entre producción y staging; utilizan bases de datos completamente separadas. Asegúrese de que no sea el caso de sus sitios de producción y staging.
Si no está seguro de que los ID de usuario coincidan entre producción y staging, y el parámetro require_activation no se está estableciendo en true en la carga útil de SSO, puede eliminar de forma segura todas las entradas existentes de SingleSignOnRecord de la base de datos de Discourse antes de cambiar al sitio de producción. La primera vez que los usuarios existentes inicien sesión en Discourse a través de WordPress, Discourse los encontrará basándose en su dirección de correo electrónico y generará un nuevo SingleSignOnRecord para ellos.
Las entradas existentes de SingleSignOnRecord se pueden eliminar de la consola de Rails con:
SingleSignOnRecord.destroy_all
Si el parámetro require_activation se está estableciendo en true en la carga útil de SSO, aún puede eliminar los registros de SSO en el lado de Discourse. Antes de que los usuarios existentes puedan iniciar sesión en Discourse desde su sitio de producción, deberá marcar sus direcciones de correo electrónico como verificadas en WordPress. Los detalles sobre cómo hacerlo desde sus páginas de perfil de WordPress están aquí: Validate Email Addresses with the WP Discourse plugin.
Si tienes un sitio de WordPress de staging, te recomiendo encarecidamente que también tengas un foro de Discourse de staging. De esa manera, no tendrás que preocuparte por lo que podría suceder si conectas tu WordPress de staging a un Discourse de producción.
Este es un escenario común: alguien crea un sitio en algún servicio de alojamiento de WordPress (por ejemplo, WP Engine), prueba las cosas en el sitio de staging predeterminado y luego cambia a producción. Respondí la misma pregunta varias veces cuando brindaba soporte para Discourse. Un sitio de staging separado y permanente para Discourse generalmente no era una opción (o realmente no era necesario).
1 me gusta
Sí, tienes razón, es un escenario relativamente común.
Sin embargo, si tu WordPress está en producción, como parece ser el caso de este colega (@Firsh, corrígeme si me equivoco), entonces creo que el riesgo/costo potencial de mezclar entornos de staging y producción supera cualquier ahorro de tiempo y costo que se obtenga simplemente al iniciar una instancia separada de Discourse. Esto asumiendo que tu staging es una copia de tu producción (lo cual suele ser el caso).
A menos que existan restricciones organizacionales para iniciar nuevas instancias (en cuyo caso, probablemente deberías tener un entorno de staging separado de todos modos), es relativamente barato y fácil iniciar una instancia separada de Discourse en DigitalOcean, Vultr, etc., y evitar cualquier problema que pueda surgir de la polinización cruzada Staging ↔ Producción. Probablemente ahorrarás tiempo (y dinero-como-tiempo) al hacerlo. Simplemente puedes apagarla cuando hayas terminado.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.