Intentamos y nos encontramos con estos problemas: ha importado todas las publicaciones, pero los títulos de los temas no aparecen y las imágenes externas no se renderizan. El foro SMF2 actual es: https://forum.mundofotografico.com.br estamos intentando migrar a Discourse aquí: https://discourse.fotografos.online - Todos los temas y descripciones adecuadas no se transfirieron, las imágenes no se cargan… ¡por favor ayuden! @marcozambi @miligraf @FireAllianceNX @pfaffman
Estoy comenzando el proceso de migración de SMF y actualmente estoy importando publicaciones en una instancia de prueba a aproximadamente 1000/hora, así que todo va bien hasta ahora, aparte del script de rendimiento de MySQL, donde MySQL no le gustó el comando ‘ALTER USER’ por alguna razón. Manualmente ejecuté un ‘CREATE USER’ y todo salió bien después de eso.
Leí el comentario sobre los usuarios eliminados, pero no puedo crear fácilmente nuevos usuarios/correos electrónicos falsos para cubrir a todos mis usuarios eliminados (mi foro ha estado funcionando durante más de 20 años y probablemente tengo más usuarios eliminados que usuarios reales ahora). Sospecho que tengo entre 4000 y 5000 usuarios eliminados. No todos habrán publicado, pero muchos lo habrán hecho, así que probablemente tengo cientos de usuarios ‘faltantes’.
Las publicaciones se están importando como si pertenecieran a ‘system’, lo cual no es ideal. Me preguntaba si lo siguiente funcionaría.
- Antes de importar, crea un usuario ficticio, por ejemplo, ‘Usuario Eliminado’.
- Averigua el número de usuario de ‘Usuario Eliminado’.
- Modifica la línea “user_id: user_id_from_imported_user_id(message[:id_member]) || -1,” en smf2.rb y reemplaza el ‘-1’ con el número de usuario de ‘Usuario Eliminado’ (¿creo que el usuario del sistema es -1?).
¿Funcionaría eso? Además, ¿hay otros lugares en smf2.rb donde necesitaría hacer un cambio similar?
Hola, ¿por “eliminados” te refieres a que están realmente eliminados de la base de datos de SMF, o todavía están en la base de datos con su nombre de usuario y correo electrónico y marcados como suspendidos? ¿Cómo se muestran actualmente en SMF las publicaciones de esos usuarios “eliminados”?
Estoy en medio de una gran migración de Drupal a Discourse, también de un foro de larga data con toneladas de usuarios suspendidos. Definitivamente quería mantener esos mismos nombres de usuario suspendidos y sus direcciones de correo electrónico asociadas en Discourse, así que tuve que agregar esa función al script de importación de Drupal para Discourse. Básicamente, el script importa a todos los usuarios como usuarios activos normales, y si tenían alguna publicación visible públicamente, también se importarán como en el foro original. Luego, al final del proceso, agregué una función que tomé de otro script de importación para revisar la base de datos de Drupal y, si el usuario estaba marcado como suspendido, suspender también la cuenta de Discourse. Puedes ver el código de eso en mi historial de publicaciones aquí.
1 me gusta
Hola. Los usuarios se eliminan realmente, es decir, ya no hay un registro para ellos en la tabla smf_member. SMF no tiene una función para suspender usuarios. Puedes prohibir usuarios, pero eso no parece correcto para una cuenta de un usuario que ha fallecido o ha perdido interés en el hobby/foro. Tampoco es realmente correcto desde una perspectiva de protección de datos.
Las publicaciones de SMF tienen dos campos almacenados para cada registro… el número de miembro del usuario, que se establece en cero para los usuarios eliminados, y el nombre del publicador, que contiene el nombre de usuario del publicador. Por lo tanto, puedes ver qué usuario publicó el mensaje, pero ya no hay detalles disponibles (correo electrónico, nombre completo, etc.) para el usuario. Sus publicaciones tienen una marca de ‘Invitado’ cuando se muestran.
Supongo que podría crear una nueva cuenta de usuario para cada usuario que haya publicado un mensaje con un ID de miembro cero y asignar una dirección de correo electrónico ficticia para la cuenta, y luego marcar al usuario como suspendido. Podría marcar las cuentas como suspendidas basándome en el formato de la dirección de correo electrónico ficticia si usara algo único pero identificable. Sin embargo, eso se siente un poco extraño en algunos casos… ¡crear cuentas para personas que sé que murieron hace 10-15 años!
Tengo tiempo para pensar en esto… la migración funcionó parcialmente, pero ahora tengo que averiguar por qué los archivos adjuntos no se adjuntaron, los enlaces dentro del foro no se modificaron y por qué las contraseñas de los usuarios migrados no funcionan. Puede haber otros problemas también, pero trabajaré en solucionar esos problemas primero y luego veré qué más surge.
¿Te refieres a Postgres? No estoy seguro de a qué te refieres.
Lo que haría es que si el ID de usuario es 0, usar el nombre de usuario para el ID. Luego, si find_username_by_import_id no encuentra al usuario, crea el usuario, estableciendo la dirección de correo electrónico en fake_email (es una función en base.rb que genera una dirección de correo electrónico falsa) y el nombre de usuario con el nombre de usuario que tienes. Luego, si eres ambicioso, podrías, al final del script, suspender a todos los usuarios que tengan @email.invalid en su dirección de correo electrónico. No estarán activos, así que no creo que importe mucho si no los suspendes.
Otra forma sería hacer una consulta que de alguna manera generara una lista de todos los usuarios eliminados y luego crearlos antes de empezar a publicar, pero eso parece más difícil.
Si quieres crear un usuario usuario eliminado y que todas esas publicaciones sean propiedad de ese usuario en lugar de system, podrías hacerlo y simplemente reemplazar el -1 con el número de usuario de usuario eliminado. Podrías crearlo como un usuario normal o hacer algo elegante y darle un ID de usuario de -2 o algo así.
En algunos sistemas, esto se debe a que a veces los archivos adjuntos están en el cuerpo de la publicación y, en otros, el registro del archivo adjunto está en la base de datos.
¿Instalaste el plugin Soporte para hashes de contraseñas migrados después de ejecutar la importación (puede interferir con la ejecución de importaciones en al menos algunas circunstancias)? ¿SMF2 hashea las contraseñas de la misma manera que smf lo hace?
Lo siento, nombre incorrecto para el script. Es el script de MySQL al que se hace referencia en la primera publicación.
– file: ~/smf2/script_for_mysql_tuning.sql
ALTER USER ‘user’@‘%’ IDENTIFIED WITH mysql_native_password BY ‘pass’;
Gracias por las sugerencias sobre usuarios y, en particular, sobre fake_email. ¡Mi primera tarea es aprender suficiente Ruby para poder hacer cambios en el script de importación!
Los archivos adjuntos de SMF2 son registros en la base de datos. Habiendo investigado un poco más, parece que algunos han sido importados, pero solo unos pocos cientos de decenas de miles. Seguiré investigando para ver si puedo averiguar por qué.
¡Ah, eso es probablemente lo que me falta! Estoy bastante seguro de que SMF2 usa el mismo hashing (MD5 con sal, si no recuerdo mal) que SMF1, por lo que el plugin con suerte solucionará el problema. Necesito hacer más ejecuciones de importación antes de preocuparme demasiado por el inicio de sesión de los usuarios.
Me surge otra pregunta. ¿Hay alguna forma de restablecer el sistema para permitirme hacer otra importación? Debería haber hecho una copia de seguridad antes de empezar, pero lo olvidé 
Oh. Te refieres a configurar mysql. Ya veo.
Si conoces otros idiomas, probablemente puedas arreglártelas.
Escribí varios importadores antes de hacer nada parecido a aprender Ruby. 
Aquí tienes una forma de eliminar y crear una nueva base de datos de Discourse.
sv stop unicorn;DISABLE_DATABASE_ENVIRONMENT_CHECK=1 IMPORT=1 rake db:drop db:create db:migrate; sv start unicorn
Si puedes recordar hacer una copia de seguridad, puede ser un poco más rápido. Quizás.
Otro truco, una vez que tengas los usuarios configurados, es detener el script después de importar los usuarios y hacer una copia de seguridad en ese momento. Eso te permitirá depurar la importación de publicaciones sin tener que importar a todos los usuarios de nuevo.
Sé algunos. Escribí mi primer programa en 1976 en código máquina binario en un Intel 4004. Estoy empezando a entender smf2.rb con un poco de DuckDuckGo para comprender algunas de las estructuras de código que son nuevas para mí.
Gracias por el método de eliminación/creación de la base de datos. Es hora de empezar de nuevo y ver si puedo hacer algunos cambios incrementales en el importador para mis datos.
1 me gusta
He logrado modificar el importador para crear cuentas ficticias con una dirección de correo electrónico falsa para los usuarios eliminados y las cuentas ficticias son propietarias de sus publicaciones correctas, así que ese es un buen comienzo.
Estoy intentando entender los archivos adjuntos a continuación porque no veo ninguno en ninguna de las publicaciones que he importado hasta ahora (y debería haber algunos).
Si creo un mensaje normalmente a través de la página web de Discourse, obtengo un registro en la tabla posts (id=4346), dos registros en la tabla uploads (ids=403 y 404), cuatro registros en upload_references (403/Draft/4, 403/Post/4346, 404/Draft/4, 404/Post/4346). También veo 403 en el campo image_upload_id para la publicación 4346 y HTML que hace referencia a las dos cargas en el campo posts/cooked.
Para las publicaciones importadas, obtengo un registro en la tabla posts para cada mensaje SMF importado y un registro en la tabla uploads para cada archivo adjunto asociado con un mensaje SMF importado. Los registros de la tabla uploads hacen referencia a archivos en disco que contienen las imágenes correctas, por lo que esa parte funciona bien. Sin embargo, no obtengo ningún registro de upload_references para las imágenes cargadas ni ninguno de los IDs de carga en el campo image_upload_id de la tabla posts.
Supongo que necesito intentar que se creen los registros de upload_references y se rellenen los campos posts-image_upload_id y cooked, pero quería comprobar primero si no hay alguna otra forma de asociar las cargas con las publicaciones que está utilizando (o intentando utilizar) el importador.
Parece que necesitas agregar una referencia al host/carga en raw. Hay alguna función que generará un enlace para ti. No recuerdo cómo se llama. Creo que está en el modelo de cargas, pero podría ser más fácil encontrarlo en algún otro script de importación si no sabes qué es un modelo.
Estaba progresando modificando el script de importación para adaptarlo a las peculiaridades de mi foro, pero me detuve en seco hace un par de días. Después de la última actualización de Discourse beta, ya no puedo compilar el contenedor de importación. Obtengo…
> FAILED
> --------------------
> Pups::ExecError: cd /var/www/discourse && apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y libmariadb-dev failed with return #<Process::Status: pid 439 exit 100>
> Location of failure: /usr/local/lib/ruby/gems/3.1.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
> exec failed with the params {"cd"=>"$home", "cmd"=>["echo \"gem 'mysql2'\" >> Gemfile", "apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y libmariadb-dev", "su discourse -c 'bundle config unset deployment'", "su discourse -c 'bundle install --no-deployment --path vendor/bundle --jobs 4 --without test development'"]}
> bootstrap failed with exit code 100
> ** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
He visto las publicaciones sobre la expiración de la clave de yarn y la he solucionado. Eso estaba impidiendo la instalación del paquete libmariadb-dev, pero hice una instalación manual del paquete que ha funcionado correctamente. La reconstrucción de la importación todavía no funciona con la plantilla de importación de mysql habilitada, incluso después de instalar manualmente el paquete MariaDB.
He creado un nuevo servidor y comencé con una instalación limpia de Discourse solo para evitar posibles problemas con el servidor/instalación anterior. Sin embargo, el nuevo servidor presenta el mismo error que el anterior.
No tengo ideas sobre qué intentar a continuación, ¡así que agradeceré cualquier sugerencia!
Ver Apt-get update fails inside container yarn repo not signed - #5 by pfaffman. Necesitarás editar la plantilla de mysql.
1 me gusta
Gracias por indicarme la dirección correcta. ¡Ahora veo lo que hice mal!
1 me gusta
Estamos comenzando con la migración de prueba de un foro SMF 2 (precisamente v2.0.15) y uno de los primeros problemas que surgieron es un problema cuando las categorías tienen un ampersand en su nombre:
Los títulos de los hilos con el mismo parecen estar bien:
Hasta ahora, parece que el ampersand es el único carácter problemático y, por ejemplo, las umlauts alemanas están bien:
Probablemente también nos afecten los problemas informados aquí en el hilo (usuarios eliminados, archivos adjuntos, enlaces dentro del foro), pero la importación aún se está ejecutando, así que actualizaré una vez que haya finalizado.
En este sentido, me pregunto si la velocidad de importación es realmente tan lenta. Actualmente estamos importando a 1750 elementos/min (inicialmente estaba un poco más cerca de 2000 elementos/min) en una máquina AMD Ryzen 5 3600 con 64 GB de RAM (Hetzner, Ubuntu 22.04), lo que pone toda la migración en aproximadamente 3 días.
Esa es una velocidad bastante buena.
Imagino que los problemas reportados aún existen, aunque un número sorprendente de cosas son exclusivas de un foro. Si quieres que se arreglen algunas cosas y tienes presupuesto, estaré encantado de ayudarte.
1 me gusta
¡Gracias! Me pondré en contacto contigo una vez que las cosas sean más concretas.
Ahora mismo nosotros (una pequeña organización sin ánimo de lucro centrada en juegos de rol de mesa y aficiones relacionadas) estamos en fase de evaluación: hay consenso en que queremos un nuevo software y Discourse, hasta ahora, es la opción favorita. Pero tendremos que recopilar todos los quehaceres (migración, nuevo tema, nuevos plugins/componentes de tema si es necesario) y ver si podemos encajar todo en nuestro presupuesto.
1 me gusta
¿Hay alguna razón especial para este paso?
Por lo que puedo ver al releer atentamente el OP, ese archivo smf2.rb no se ha modificado/parcheado.
Y si smf2.rb se encuentra en el host en (por ejemplo) /var/discourse/smf2 y has configurado tu montaje de volumen en el Paso 2 en consecuencia, de todos modos se monta en el interior del invitado en /shared/smf2.
No entiendo la necesidad de copiarlo como un paso separado. Pero entender esto puede ser la clave para descubrir por qué el 95% de los archivos adjuntos no son encontrados correctamente por el script…
1 me gusta
Suena a que tienes razón sobre la (falta de necesidad) de copiarlo. Quizás el autor lo cambió y sus cambios se incorporaron posteriormente al núcleo.
Si obtienes el 5% y no el 0% de los archivos adjuntos, entonces parece que algo anda mal con el script.
En algunos sistemas, hay dos formas de adjuntar archivos: una mencionándolo en el archivo (por lo que está en el texto sin formato de la publicación y se maneja de esa manera) y otra adjuntándolo a la publicación en algún metadato/tabla. Mi suposición es que tienes el 95% en tu base de datos de una manera y el script hace la otra.
¿Pero parece que podría estar intentando ambas formas? Necesitarás encontrar una publicación que tenga un archivo adjunto, mirar en la base de datos y en el sistema de archivos para ver cómo está almacenado y luego mirar el código para ver por qué no lo está obteniendo.
1 me gusta
¡Gracias @pfaffman, esto es tranquilizador! Más o menos pensé que ese era probablemente el caso, pero como estoy teniendo tantos problemas con esta importación, ¡he estado dudando de mis conocimientos y habilidades en todos los niveles!
Gracias por los consejos, todo es apreciado @pfaffman. Este es un reintento muy retrasado del mismo foro en el que estuve trabajando el año pasado. Es un trabajo pro-bono, pero podría volver a involucrarte si tienes tiempo.
Es un foro SMF2 muy antiguo que tiene archivos adjuntos en las dos formas:
\u003cid\u003e_\u003cNombre_del_archivo_SIN_mayúsculas_reglas_jpg\u003e_\u003c32caracteresprobablementehashMD50fsom4thing\u003e\u003cid\u003e_\u003c40caracteresprobablementehashSHA10fsom4thing\u003e
Todavía estoy tratando de averiguar si hay un patrón en los fallos.
Mi suposición (¡sin mirar el código!) es que uno de esos es lo que hace el script y el otro no (probablemente uno es la forma antigua, por lo que las nuevas publicaciones usan el otro método, pero no volvió atrás para arreglar las que usan el otro método).
Así que mira convert_message_body y los campos en la tabla de adjuntos. Quizás cambiaron de MD5 a SHA1 o viceversa por alguna razón.
Como dije, podría ser que una versión de estos tenga una referencia a la carga en lugar de tenerla enlazada en la tabla, por lo que harías un gsub para buscar ese patrón y luego, si coincidiera, obtendrías la clave, la buscarías en la tabla y luego harías create_upload con ese archivo…
Espero que eso sea suficiente para que empieces, pero por favor contáctame si quieres más ayuda de la que puedo ofrecerte aquí.