Hice una restauración y todos los enlaces internos tienen el dominio de URL de prueba, rompiendo todos los enlaces y no estoy seguro de por qué no tomó la URL del sitio correcta, sin entrar en el código/base de datos para hacer un reemplazo masivo, ¿alguna solución para hacerlo de otra manera?
Estaba pensando en hacer una Re-restauración?
Necesitarás entrar en la base de datos y hacer una búsqueda/reemplazo masivo.
Hay una herramienta para eso:
RAILS_ENV=production discourse remap //old.domain //new.domain
Puedes arreglarlo como se describe, pero eso no debería suceder.
¿Hiciste y restauraste la copia de seguridad usando /admin/backups?
¿Tienen ambos sistemas el nombre de host configurado correctamente?
Gracias. Parecía bastante fácil. Entré en la aplicación y la ejecuté, pero parece que no ha cambiado las instancias de las URL en las publicaciones.
Esta fue la reasignación:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
Esto se ejecutó y completó en la base de datos “default”, tardó unos minutos y luego informó “done” sin errores.
Miré algunas publicaciones elegidas y nada parecía haber cambiado en los enlaces de las URL de ninguna publicación.
Reconstruí algunas para probar dónde vi dev.domain.com en lugar de domain.com en los enlaces, pero siguen siendo los mismos.
Luego ejecuté lo mismo pero sin el https:// y obtuve este error:
Remapping tables on default...
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
Supongo que hay un mensaje de chat en la base de datos que hace que se detenga, pero no estoy seguro de por qué. Supongo que necesito ver eso de alguna manera en la base de datos, ya que, como puedes ver, mi incursión habitual en la gestión de Discourse nunca es en la base de datos.
Finalmente, volví a ejecutar la reasignación original, tardó unos minutos e informó “done” sin errores:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
¿Quizás necesito volver a hornear las publicaciones para ver los resultados?
Pensé que una reconstrucción de publicación era la misma acción pero a nivel de publicación individual.
¿O reconstruir la aplicación?
Eso debería ser
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
La razón de // es que coincide con http://, https:// y URL sin protocolo, y no coincide con dominios de direcciones de correo electrónico.
¿Qué sucede cuando haces eso?
Sí, está bien, entonces el mismo error de nuevo:
Remapping tables on default...
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
¡Así que al menos estoy usando el comando de escritura correcto, las cosas van bien! 
¿No hay más ideas?
Aparte de este punto muerto de reasignación de Rails, pensé que tal vez si hacía una copia de seguridad de la base de datos y la restauraba de nuevo, ¿podría reasignar correctamente las URL de enlace durante el proceso de restauración?
El error que sigo encontrando parece ser repetido o muy similar al error de detención que necesitaba una corrección aquí:
Error: ERROR: duplicate key value violates unique constraint \"index_post_hotlinked_media_on_post_id_and_url_md5\"
DETAIL: Key (post_id, md5(url::text))=...
Al intentar la reasignación:
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
¿Quizás @david tenga alguna idea al respecto?
¿Esto parece más un error?
Esa tabla tiene enlaces con ambos dominios, por lo que cuando intentas remapearlos obtienes una clave duplicada. No es un error. Estás intentando crear una clave duplicada.
Podrías eliminar los elementos de esa tabla que tengan el dominio raíz. Una mejor idea es usar www en lugar del dominio raíz.
Gracias. Mi única preocupación es que este despliegue de Discourse también sufre el problema de no-www/SSL, por ejemplo, How to add ssl to non-www domain?, ¡pero intentaré la reasignación que sugieres y si funciona me obligará a resolver también el problema de no-www!
La reconfiguración funcionó como sugirió @pfaffman, pero en realidad fue el catalizador de la solución, no la solución en sí misma, me ayudó a darme cuenta de lo que estaba haciendo mal, ¡me reconfiguró los ojos!
Si hubiera leído el error correctamente, es decir, prestado atención, lo habría resuelto hace mucho tiempo, ya que habría visto que la información clave estaba en el mensaje de error.
Todo lo que tuve que hacer fue incluir el número de publicación marcado por el error de detención …/p/123456789 en la URL para navegar directamente y corregir cada publicación manualmente.
Esto ocurrió para la mayoría en una segunda ejecución de reconfiguración para convertir el www del primer remapeo a la URL apex sin www, como era la necesidad original.
Ahora las URL internas solo deben incluir enlaces apex.
Esto resuelve parte de la redirección SSL de www donde había muchos enlaces internos antiguos de www. No resuelve a un usuario que escribe www en la barra de direcciones o un enlace de retroceso en el propio WWW por ahora, pero debería abordar todos los generados internamente. Esperando ver cómo afecta la indexación de Google antes de hacer algo más al respecto.
Quizás de interés. Para los desarrolladores.
Encontré muchas detenciones en duplicate key value violates unique constraint “unique_post_links”, estas ocurrieron cuando una publicación se movió y discourse incluyó el “Continuación de …. “ con enlace directo, pero si las publicaciones divididas incluían bloques citados al mismo lugar, entonces se detenía el remapeo.
Esto causó la mayoría de los errores de detención.
La solución fue eliminar uno de los enlaces de retroceso internos duplicados o codificarlos entre corchetes (no siempre funcionó) y el remapeo continuaría una vez re-ejecutado.
Otras detenciones fueron causadas por usuarios que creaban las mismas condiciones de publicación manualmente al volver a publicar el mismo enlace a una publicación sin darse cuenta de que la Cita también enlazaba hacia atrás, quizás hábitos históricos, estilos, etc., entran en juego aquí, lo que indica que muchos usuarios todavía no se dan cuenta de cuánto maneja discourse los enlaces para facilitar la vida, ¡oh, la ironía!
Después del remapeo, podría haber revertido las ediciones, pero no eran tantas como para marcar la diferencia y todavía había un enlace de retroceso correcto a la fuente interna de discourse de la publicación o cita.
Con suerte, esto revertirá la mayor parte de la desindexación de Google de 10.000 a 100.000 páginas a un limbo gris sin indexar.
¡Un poco de conocimiento es algo peligroso! 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.