En realidad es 3.3, así que estoy haciendo trabajos de preparación pendientes de que lleguen las PR para hacer el script compatible con esa versión de phpBB, o puede que lo intente con el script actual usando la edición que sugeriste anteriormente para la verificación de la versión…
Así que supongo que tendré que trabajar con xml_to_markdown.rb?
Mi intento de hacer una importación de prueba con un foro phpBB 3.3.x fue un gran fracaso, pero hablaré de eso más adelante.
Aprendí mucho en el proceso de probarlo y pensé en compartir lo que aprendí porque podría ser útil para otras importaciones y cuando el script de importación se actualice para phpBB 3.3.
Si necesitas editar /script/import_scripts/phpbb3/database/database.rb para superar la verificación de versión, o /script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb para agregar BBcodes personalizados, el momento de hacerlo es después de ingresar a la importación con este comando:
/var/discourse/launcher enter import
En ese momento, puedes usar nano para editar los archivos.
Dado que mi intento de ejecutar la importación en mi foro phpBB 3.3 falló, no puedo estar seguro de que mis cambios personalizados de BBcode hubieran sido efectivos, pero parece que todo lo que tienes que hacer para phpBB 3.2+ es editar el archivo:
/script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb
como se mencionó anteriormente, y agregar una definición en el formato de:
def visit_<tu BBcode personalizado sensible a mayúsculas y minúsculas aquí>(xml_node, md_node)
# el código para manejar las cosas va aquí
end
Nuevamente, aún no he podido probar esto, pero un BBcode personalizado muy común en phpBB que no aparece en la versión de xml_to_markdown.rb que tenía es este:
[YouTube]{Identifier}[/YouTube]
donde el {Identifier} es el valor “v” de la cadena de consulta de la URL de YouTube.
Así que mi intento de novato en Ruby para agregar ese código a xml_to_markdown.rb es:
def visit_YouTube(xml_node, md_node)
content = xml_node.content
url = "https://www.youtube.com/watch?v=" + content
md_node.text = "#{url}"
md_node.prefix_linebreaks = md_node.postfix_linebreaks = 2
md_node.prefix_linebreak_type = LINEBREAK_HTML
end
Finalmente, cuando ejecuté el script de importación, solo llegué al paso de carga de la base de datos y obtuve este error:
ERROR 1071 (42000) at line 1233035: Specified key was too long; max key length is 1000 bytes
No estoy seguro de si es un problema del motor de DB (el original usa InnoDB) o qué, pero sospecho que se abordará en la versión 3.3 de phpBB del script.
De acuerdo, no pude dejar esto así.
Si bien supongo que es posible que el error que obtuve pueda ser manejado por el script de importación, realmente me parece que es un problema con la estructura de la base de datos de phpBB3 y el hecho de que mi intercalación de base de datos sea UTF8. Obtuve este error al ejecutar el script de importación:
ERROR 1071 (42000) at line 1233035: Specified key was too long; max key length is 1000 bytes
Cuando miré la línea 1233035 de mi archivo phpbb_mysql.sql, estoy usando una copia local del volcado de datos, vi esto:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`),
ADD KEY `is_dynamic` (`is_dynamic`);
Al observar la columna config_name en la tabla phpbb_config, descubrí que está configurada como VARCHAR(255).
Gracias a esta publicación en Stackoverflow, descubrí que puedo usar un “índice de prefijo” para acortar la longitud de la clave. Lo probé y funciona.
Para mi base de datos phpBB 3.3.8, en realidad se vieron afectadas cuatro tablas:
Si alguien más quiere intentarlo, aquí están los pasos para la tabla phpbb_config, y al final incluiré las consultas para las otras tablas.
Calcula el valor más corto para el índice de prefijo usando esta consulta:
SELECT
ROUND(SUM(LENGTH(`config_name`)<10)*100/COUNT(`config_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`config_name`)<20)*100/COUNT(`config_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`config_name`)<50)*100/COUNT(`config_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`config_name`)<100)*100/COUNT(`config_name`),2) AS pct_length_100
FROM `phpbb_config`;
En mi caso, mostró que el 100% de las filas usaban menos de 50 caracteres, así que edité mi archivo de volcado de datos:
nano /var/discourse/shared/standalone/import/data/phpbb_mysql.sql
y usé la búsqueda Ctrl+W para la siguiente cadena:
ALTER TABLE `phpbb_config`
luego cambié esto:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`),
ADD KEY `is_dynamic` (`is_dynamic`);
a esto:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`(50)),
ADD KEY `is_dynamic` (`is_dynamic`);
El (50) que está ahí es la longitud del índice de prefijo.
En mi caso, tuve que repetir el proceso con las otras tres tablas usando estas consultas para obtener la longitud óptima de la clave de prefijo:
SELECT
ROUND(SUM(LENGTH(`config_name`)<10)*100/COUNT(`config_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`config_name`)<20)*100/COUNT(`config_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`config_name`)<50)*100/COUNT(`config_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`config_name`)<100)*100/COUNT(`config_name`),2) AS pct_length_100
FROM `phpbb_config_text`;
SELECT
ROUND(SUM(LENGTH(`migration_name`)<10)*100/COUNT(`migration_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`migration_name`)<20)*100/COUNT(`migration_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`migration_name`)<50)*100/COUNT(`migration_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`migration_name`)<100)*100/COUNT(`migration_name`),2) AS pct_length_100
FROM `phpbb_migrations`;
SELECT
ROUND(SUM(LENGTH(`provider`)<10)*100/COUNT(`provider`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`provider`)<20)*100/COUNT(`provider`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`provider`)<50)*100/COUNT(`provider`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`provider`)<100)*100/COUNT(`provider`),2) AS pct_length_100
FROM `phpbb_oauth_accounts`;
Aquí están las cadenas de búsqueda para las otras tablas para ahorrarte algo de tiempo:
ALTER TABLE `phpbb_config_text`
ALTER TABLE `phpbb_migrations`
ALTER TABLE `phpbb_oauth_accounts`
No diré que estoy fuera de peligro, pero lo anterior resolvió mi error inicial de base de datos y la importación se está ejecutando:
#import_phpbb3.sh
The phpBB3 import is starting...
Loading existing groups...
Loading existing users...
Loading existing categories...
Loading existing posts...
Loading existing topics...
importing from phpBB 3.3.8
creating users
722 / 5014 ( 14.4%) [58 items/min]
Actualización:
La importación del script finalizó en 9 horas y 28 minutos. Menos mal que tenía Screen. ¡Este script es increíble!
El post-procesamiento está en curso.
¿Hay algún registro de la salida del script de importación en algún lugar, o debería haberlo redirigido a un archivo?
¿Qué procedimiento para el importador de phpbb3 se debe utilizar al ejecutar discourse_dev en un contenedor Docker bajo WSL?
He intentado ambos procedimientos: 1. Importar usando un contenedor Docker y 2. Importar usando el entorno de desarrollo. Ninguno ha funcionado, aunque logré que el script se ejecutara hasta completarse bajo el procedimiento 1, pero ninguna data llegó realmente a la base de datos del foro a pesar de que muchas consultas parecían haber tenido éxito a medida que avanzaban. ¿Podría haber una base de datos diferente involucrada que se esté poblando debido a que la importación se ejecuta en su propio contenedor separado del contenedor discourse_dev?
En el caso del procedimiento 2, simplemente no es posible ejecutar la compilación, que falla con “Ocurrió un error al instalar tiny_tds (2.1.5), y Bundler no puede continuar”.
¿Debería intentar hacer una ‘instalación estándar’ (sin Docker, sin entorno de desarrollo) en WSL y luego hacer la importación basada en Docker?
Eso es lo que recomiendo. Rara vez hago una migración en desarrollo.
Además, no necesitas tiny_tds, a menos que estés usando mssql en lugar de mysql/mariadb.
Muchas gracias, Jay. Tus tutoriales han sido muy acertados, te agradezco mucho que los tengas.
Instalé Discourse con éxito en un nuevo VPS utilizando el proceso de instalación estándar de Docker. Luego ejecuté el proceso de importación siguiendo estas instrucciones y el script finalizó sin problemas. Salí del contenedor y luego detuve la importación, recibiendo el mensaje de que:
''Tienes menos de 5 GB de espacio libre en el disco donde se encuentra /var/lib/docker. Necesitarás más espacio para continuar
Sistema de archivos Tamaño Usado Disponible Uso% Montado en
/dev/vda1 24G 20G 2.7G 89% /
¿Te gustaría intentar recuperar espacio limpiando imágenes y contenedores de docker en el sistema? (s/N)‘’
La recuperación de espacio no produjo espacio adicional. Entonces, ¿cómo proceder? ¿Puedo eliminar de forma segura todos los archivos de imagen que subí a /data? No estoy seguro si todavía son necesarios.
Gracias.
Si la importación parece haber finalizado y te refieres a las imágenes que deberían haberse importado, debería estar bien, pero es probable que no tengas suficiente espacio para hacer una copia de seguridad. Te recomendaría mejorar el droplet para que tenga más espacio. El precio por día no debería ser un gran problema.
Gracias por este consejo, Jay.
En caso de que estos detalles sean útiles para otros, eliminé (solo) los archivos de imagen, lo que liberó ~ 3.4 GB para un total de 6.1 GB disponibles y Sidekiq luego procesó con éxito el posprocesamiento. El espacio en disco se ha incrementado desde entonces en 20 GB adicionales.
Para que conste, se trató de una importación de un foro phpBB versión 3.3.0 con poco más de 73.000 publicaciones en poco más de 8.000 temas con poco más de 1300 usuarios.
El único problema que he encontrado, hasta ahora, es que algunos nombres de usuario son raros, pero eso se discutió anteriormente y no es fatal.
Habrá un intervalo entre esta importación y el cierre del foro phpBB de origen. ¿Puedo simplemente dejar el contenedor Docker de importación en su lugar y luego usarlo en una copia de seguridad incremental para migrar las publicaciones realizadas después de esta importación?
Cuando hice mi migración de phpBB 3.3.x, para hacer mi importación final, puse el sitio phpBB en "modo de mantenimiento", usé rsync para actualizar los archivos adjuntos, avatares y smilies, luego importé un nuevo volcado de datos, y tuve que reconstruir la importación para hacer la ejecución final del script de importación, pero había salido de la importación antes de eso.
@DonH ¿Importaste las contraseñas de phpBB y lograste que funcionaran con el plugin Migrate Passwords?
No importé las contraseñas de phpBB por un par de razones. No quería posibles conflictos con plugins y quería obligar a la gente a actualizar sus contraseñas, y esta migración parecía una buena manera (y una buena excusa) para hacerlo. La seguridad en el host web de phpBB la maneja la empresa de hosting, con el nuevo VPS no existe tal lujo.
Para ser claro, ¿reimportaste tu base de datos completa por última vez y no hiciste una actualización incremental?
Mi entendimiento, y experiencia, es que si haces un volcado de datos de tu foro phpBB —desde phpMyAdmin, por ejemplo— y subes el archivo a /var/discourse/shared/standalone/import/data, reconstruyes la importación y luego vuelves a ejecutar el comando de importación, el script de migración no tocará las cuentas de usuario, publicaciones, etc. ya importadas, solo las entradas de la base de datos que no se importaron previamente.
En esencia, está haciendo una actualización incremental, pero no toca las entradas existentes, por lo que podrías perder algunos datos; por ejemplo, si un usuario editó una publicación ya importada o cambió su dirección de correo electrónico.
Si deja la configuración del plugin migratepassword_allow_insecure_passwords sin marcar, el plugin migratepassword no permitirá contraseñas migradas que Discourse considere inseguras, respetando todas las configuraciones de complejidad como la longitud mínima y los caracteres únicos.
¿No está seguro de a qué tipo de conflictos de plugins se refiere?
@RGJ ¿Funcionará el plugin migratepassword con phpBB 3.3?
Estoy en proceso de realizar una importación con un foro phpBB 3.3.8 en este momento, y estoy importando las contraseñas para intentarlo.
¿Cómo podría migrar desde myBB?
Puedes buscar myBB y la etiqueta #migration::tag, tal vez encuentres un howto
Ok, ¡gracias por la información!
Gracias por esa aclaración, Richard. No me refería a ningún conflicto específico, solo a la posibilidad de que ocurriera algo inesperado en un territorio desconocido. Hice la importación deliberadamente antes de añadir ningún plugin. Sobre todo, sin embargo, quiero obligar a nuestros miembros a actualizar sus contraseñas.
Esta migración se realizó sin problemas, así que enhorabuena a Gerhard y a todos los demás involucrados por un script bien equilibrado. Estoy deseando adaptar nuestro nuevo tablón de mensajes.
Sí, lo hará, recientemente añadimos soporte para Argon2 en el plugin.
Richard soporta el plugin en su hosting. Nunca he oído que cause problemas. Muchos importadores importan las contraseñas y funciona. Incluso funcionó para un script de importación que escribí para otro foro aleatorio.