Ah, ahora tiene más sentido
Puedes verificarlo localmente con cualquier cliente SSH que prefieras. Dependiendo de tu configuración, los archivos deberían estar en algo como /var/discourse/shared/standalone/uploads/default/original/2X/
Así que podrías ejecutar ls -R /var/discourse/shared/standalone/uploads/ | grep 4064b para encontrar el archivo 4064b…d.png.
Hablo de la misma instancia de Discourse que @masterakay.
Hace más de dos años que migramos a S3; ninguno de los archivos en el directorio de subidas local es posterior a 2018.
Según entiendo, las imágenes se suben a la carpeta “original”, se procesan (se recortan, se reduce su tamaño, etc.) y se colocan en la carpeta “optimized”. Las URL que utiliza Discourse al subir imágenes siguen siendo de la carpeta “/original/1X/”. De alguna manera, con la actualización, la carpeta “1X” ha desaparecido.
Existe una carpeta “default” que contiene muchas subidas (imágenes, etc.) así como versiones recortadas. Hay alrededor de 10 000 archivos aquí, lo que suma aproximadamente 2,5 GB.
El problema es que la URL de la imagen en las publicaciones siempre apunta a la versión “original”.
Algo que notamos es que los archivos faltantes son un subconjunto de los archivos de la carpeta “default”.
Las nuevas subidas funcionan sin problemas y se almacenan en “/original/2X/”.
¿Alguien tiene alguna idea de dónde pudo haber ido la carpeta “/original/1X/” y si es posible recuperarla?
@sam@codinghorror Siento mucho involucrarlos en esto, pero es bastante urgente. Somos estudiantes y estamos bastante indefensos ante la presión que el colegio nos ejerce para arreglar las imágenes.
¿Cómo configuraste S3? ¿Estableciste algún valor en app.yml o solo en la interfaz de administración? Parece que algo es inesperado para DISCOURSE_S3_BUCKET o DISCOURSE_S3_BACKUP_BUCKET.
Efectivamente. Algo podría no estar funcionando correctamente en el código, pero no sabemos qué ni por qué. Por lo tanto, necesitamos más información.
Existen dos formas diferentes de configurar S3: puedes configurar el entorno en app.yml o puedes ingresar los valores en la interfaz de administración de la aplicación. Las variables tienen nombres ligeramente diferentes en cada caso.
El tema al que has enlazado describe cómo configurar en la interfaz de administración. Si así es como configuraste tu sitio, ¿podrías decirnos qué valores tienes para s3_upload_bucket y s3_backup_bucket?
@schleifer A mí también me ocurre. Tampoco he modificado nada en esa configuración. Además, he verificado que mis credenciales de AWS funcionan correctamente.
El problema ocurrió porque esas configuraciones no deberían tener el mismo valor: busca en el tema de configuración la línea “¿Realmente necesito usar cubetas separadas para las cargas y las copias de seguridad?”. Un trabajo de mantenimiento se ejecutó sobre el contenido de la cubeta de copias de seguridad y afectó a las cargas porque sus valores se superpusieron.
@sam, probablemente deberíamos hacer cumplir esto en el código, no solo en la documentación.
Para arreglar tu sitio, hay dos pasos:
Primero, necesitarás cambiar el prefijo de las copias de seguridad: añadir /backups al final, como se describe en el tema de configuración, es suficiente.
Después, mueve todo lo que hay en la cubeta de S3 de nuevo al lugar correcto. Todo lo que esté en la carpeta superior “default” debe volver al nivel superior.
Por ejemplo, probablemente haya una carpeta “default/originals” que debería moverse hacia arriba.
Tendrás que usar la consola web de AWS o alguna otra herramienta para explorar la cubeta.
Hola @schleifer, tiene sentido y he añadido el prefijo de copias de seguridad al nombre del bucket.
En cuanto a las cargas existentes, todas están en /default/ (no en subcarpetas). Las URLs de las imágenes en los publicaciones (y en todas partes) usan /original/* o /optimized/*.
Si movemos todo lo que está en la carpeta default un nivel hacia arriba (a la raíz), las imágenes estarán en /*.
Y no, no hay carpetas dentro de defaults, solo archivos de carga. Parece que contiene archivos con nombres de hash estándar de 40 caracteres, así como algunos con sufijos como “_2_10x10” (que presumiblemente son de las versiones optimizadas).
¿Cómo sugieres solucionar esto? Corregir todas las publicaciones con nuevos enlaces llevará tiempo. ¿Es posible agrupar de alguna manera los archivos en las carpetas correctas basándose en este nombre de archivo?
Eso es… inesperado. Tendremos que arreglar un montón de cosas a mano, entonces.
La pregunta más importante sería: “¿las nuevas subidas van al lugar correcto?”
Asumiendo que eso es cierto, puedes colocar las subidas antiguas en una ubicación conocida y ajustar su entrada en la base de datos. ¿Cuántos archivos hay en /default/?
Afortunadamente, las nuevas subidas están funcionando como se esperaba en las subcarpetas. Y los enlaces en las publicaciones apuntan a la ubicación correcta.
Hay más de 10k archivos en /default/. Editar cada publicación manualmente parece ser mucho trabajo. ¿Hay alguna manera de automatizar esto? ¿Quizás con una sustitución mediante expresión regular en todas las publicaciones?
Ese es el plan, sí. Lo siguiente es colocar todos los archivos AWOL en una ubicación conocida. En el bucket, ¿qué subdirectorios hay bajo /original/? Debería haber /1X/ y puede que haya otros.
