C’est en fait 3.3, donc je fais des préparatifs en attendant que les PR rendent le script compatible avec cette version de phpBB, ou je pourrais essayer avec le script actuel en utilisant la modification que vous avez suggérée plus tôt pour la vérification de la version…
Donc, je suppose que je devrai travailler avec xml_to_markdown.rb ?
Ma tentative d’importation de test avec un forum phpBB 3.3.x a été un gros échec, mais j’en parlerai plus tard.
J’ai beaucoup appris en essayant, et j’ai pensé partager ce que j’ai appris car cela pourrait être utile pour d’autres importations et lorsque le script d’importation sera mis à jour pour phpBB 3.3.
Si vous avez besoin de modifier /script/import_scripts/phpbb3/database/database.rb pour passer la vérification de version, ou /script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb pour ajouter des BBcodes personnalisés, le moment de le faire est après être entré dans l’importation avec cette commande :
/var/discourse/launcher enter import
À ce moment-là, vous pouvez utiliser nano pour modifier les fichiers.
Comme ma tentative d’exécuter l’importation sur mon forum phpBB 3.3 a échoué, je ne peux pas être sûr que mes modifications de BBcode personnalisés auraient été efficaces, mais il semble que tout ce que vous avez à faire pour phpBB 3.2+ est de modifier le fichier :
/script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb
comme indiqué ci-dessus, et d’ajouter une définition du type :
def visit_<votre BBcode personnalisé sensible à la casse ici>(xml_node, md_node)
# le code pour gérer les choses va ici
end
Encore une fois, je n’ai pas encore pu tester cela, mais un BBcode personnalisé très courant dans phpBB qui n’apparaît pas dans la version de xml_to_markdown.rb que j’avais est celui-ci :
[YouTube]{Identifier}[/YouTube]
où {Identifier} est la valeur “v” de la chaîne de requête de l’URL YouTube.
Donc, ma tentative de noob en Ruby pour ajouter ce code à xml_to_markdown.rb est :
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
Enfin, lorsque j’ai exécuté le script d’importation, je n’ai atteint que l’étape de chargement de la base de données, et j’ai obtenu cette erreur :
ERROR 1071 (42000) at line 1233035: Specified key was too long; max key length is 1000 bytes
Je ne suis pas sûr si c’est un problème de moteur de base de données - l’original utilise InnoDB - ou quoi, mais je soupçonne que cela sera résolu dans la version 3.3 du script pour phpBB.
D’accord, je n’ai pas pu laisser tomber ça.
Bien que je suppose qu’il soit possible que l’erreur que j’ai obtenue puisse être gérée par le script d’importation, il me semble vraiment qu’il s’agit d’un problème avec la structure de la base de données de phpBB3, et le fait que mon collation de base de données soit UTF8. J’ai obtenu cette erreur en exécutant le script d’importation :
ERROR 1071 (42000) at line 1233035: Specified key was too long; max key length is 1000 bytes
Lorsque j’ai regardé la ligne 1233035 de mon fichier phpbb_mysql.sql - j’utilise une copie locale du dump de données - j’ai vu ceci :
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`),
ADD KEY `is_dynamic` (`is_dynamic`);
En regardant la colonne config_name dans la table phpbb_config, j’ai constaté qu’elle était définie sur VARCHAR(255).
Grâce à ce post sur Stackoverflow, j’ai découvert que je peux utiliser un “index de préfixe” pour réduire la longueur de la clé. Je l’ai testé, et ça marche.
Pour ma base de données phpBB 3.3.8, quatre tables ont été affectées :
Si d’autres personnes veulent essayer, voici les étapes pour la table phpbb_config, et j’inclurai les requêtes pour les autres tables à la fin.
Calculez la plus petite valeur pour l’index de préfixe en utilisant cette requête :
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`;
Dans mon cas, il a montré que 100 % des lignes utilisaient moins de 50 caractères, j’ai donc modifié mon fichier de dump de données :
nano /var/discourse/shared/standalone/import/data/phpbb_mysql.sql
et j’ai utilisé la recherche Ctrl+W pour la chaîne suivante :
ALTER TABLE `phpbb_config`
puis j’ai changé ceci :
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`),
ADD KEY `is_dynamic` (`is_dynamic`);
en ceci :
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`(50)),
ADD KEY `is_dynamic` (`is_dynamic`);
Le (50) ici est la longueur de l’index de préfixe.
Dans mon cas, j’ai dû répéter le processus avec les trois autres tables en utilisant ces requêtes pour obtenir la longueur optimale de la clé de préfixe :
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`;
Voici les chaînes de recherche pour les autres tables pour vous faire gagner du temps :
ALTER TABLE `phpbb_config_text`
ALTER TABLE `phpbb_migrations`
ALTER TABLE `phpbb_oauth_accounts`
Je ne dirai pas que je suis sorti d’affaire, mais ce qui précède a résolu mon erreur initiale de base de données, et l’importation est en cours :
#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]
Mise à jour :
Le script d’importation s’est terminé en 9 heures et 28 minutes. Dieu merci pour Screen. Ce script est génial !
Le post-traitement est maintenant en cours.
Existe-t-il un journal de la sortie du script d’importation quelque part, ou aurais-je dû le rediriger vers un fichier ?
Quelle procédure pour l’importateur phpbb3 doit être utilisée lors de l’exécution de discourse_dev dans un conteneur Docker sous WSL ?
J’ai essayé les deux procédures : 1. Importation à l’aide d’un conteneur Docker et 2. Importation à l’aide de l’environnement de développement. Aucune n’a fonctionné, bien que j’aie réussi à exécuter le script jusqu’à la fin dans le cadre de la procédure 1, mais aucune donnée n’a réellement été intégrée à la base de données du forum malgré le succès apparent de nombreuses requêtes au fur et à mesure. Y a-t-il une base de données différente qui est remplie car l’importation est exécutée dans son propre conteneur, séparé du conteneur discourse_dev ?
Dans le cas de la procédure 2, il est tout simplement impossible d’exécuter la compilation qui échoue avec “Une erreur s’est produite lors de l’installation de tiny_tds (2.1.5), et Bundler ne peut pas continuer.”
Dois-je essayer de faire une “installation standard” (sans Docker, sans environnement de développement) dans WSL, puis effectuer l’importation basée sur Docker ?
C’est ce que je recommande. Je fais très rarement une migration en développement maintenant.
De plus, vous n’avez pas besoin de tiny_tds, à moins que vous n’utilisiez mssql plutôt que mysql/mariadb.
Merci beaucoup, Jay. Vos tutoriels ont été parfaits, je vous suis très reconnaissant de les avoir.
J’ai installé avec succès Discourse sur un nouveau VPS en utilisant le processus d’installation Docker standard. J’ai ensuite exécuté le processus d’importation conformément à ces instructions et le script s’est terminé sans problème. J’ai quitté le conteneur, puis j’ai arrêté l’importation et j’ai reçu le message suivant :
« Il vous reste moins de 5 Go d’espace libre sur le disque où se trouve /var/lib/docker. Vous aurez besoin de plus d’espace pour continuer
Système de fichiers Taille Utilisé Disponible Util% Monté sur
/dev/vda1 24G 20G 2,7G 89% /
Souhaitez-vous tenter de récupérer de l’espace en nettoyant les images et conteneurs Docker du système ? (o/N) »
La récupération d’espace n’a pas libéré d’espace supplémentaire. Comment procéder ? Puis-je supprimer en toute sécurité tous les fichiers image que j’ai téléchargés dans /data ? Je ne suis pas sûr s’ils sont encore nécessaires.
Merci.
Si l’importation semble terminée et que vous parlez des images qui auraient dû être importées, cela devrait aller, mais vous n’aurez probablement pas assez d’espace pour faire une sauvegarde. Je mettrais à niveau le droplet pour avoir plus d’espace. Le prix par jour ne devrait pas être un problème.
Merci pour ces conseils, Jay.
Au cas où ces détails seraient utiles à d’autres, j’ai supprimé uniquement les fichiers image, ce qui a libéré environ 3,4 Go pour un total de 6,1 Go disponibles, et Sidekiq a ensuite réussi à traiter le post-traitement. L’espace disque a depuis été augmenté de 20 Go supplémentaires.
Pour mémoire, il s’agissait d’une importation d’un forum phpBB version 3.3.0 avec un peu plus de 73 000 messages dans un peu plus de 8 000 sujets avec un peu plus de 1300 utilisateurs.
Le seul problème que j’ai trouvé jusqu’à présent est que certains noms d’utilisateur sont étranges, mais cela a été discuté ci-dessus et n’est pas fatal.
Il y aura un intervalle entre cette importation et la fermeture du forum phpBB source. Puis-je simplement laisser le conteneur Docker d’importation en place et l’utiliser ensuite sur une sauvegarde incrémentielle pour migrer les messages postés après cette importation ?
Lorsque j’ai effectué ma migration de phpBB 3.3.x, pour effectuer mon importation finale, j’ai mis le site phpBB en « mode maintenance », j’ai utilisé rsync pour mettre à jour les pièces jointes, les avatars et les émoticônes, puis j’ai importé un nouveau dump de données, et j’ai dû reconstruire l’importation pour effectuer l’exécution finale du script d’importation, mais j’avais quitté l’importation avant cela.
@DonH Avez-vous importé les mots de passe phpBB et les avez-vous fait fonctionner avec le plugin Migrate Passwords ?
Je n’ai pas importé les mots de passe phpBB pour plusieurs raisons. Je ne voulais aucun conflit potentiel avec les plugins et je voulais forcer les gens à mettre à jour leurs mots de passe, et cette migration semblait être une bonne façon (et une bonne excuse) de le faire. La sécurité sur l’hébergeur web phpBB est gérée par la société d’hébergement, avec le nouveau VPS, il n’y a pas un tel luxe.
Pour être clair, avez-vous réimporté toute votre base de données une dernière fois et n’avez-vous pas fait de mise à jour incrémentielle ?
D’après ma compréhension et mon expérience, si vous effectuez un vidage de données de votre forum phpBB — depuis phpMyAdmin, par exemple — et téléchargez le fichier dans /var/discourse/shared/standalone/import/data, reconstruisez l’importation, puis relancez la commande d’importation, le script de migration ne touchera pas les comptes d’utilisateurs, les publications, etc. déjà importés, seulement les entrées de base de données qui n’ont pas été importées précédemment.
Essentiellement, cela effectue une mise à jour incrémentielle, mais cela ne touche pas les entrées existantes, vous pourriez donc perdre certaines données ; par exemple, si un utilisateur a modifié une publication déjà importée ou changé son adresse e-mail.
Si vous laissez le paramètre du plugin migratepassword_allow_insecure_passwords décoché, le plugin migratepassword n’autorisera pas les mots de passe migrés jugés non sécurisés par Discourse, honorant tous les paramètres de complexité tels que la longueur minimale et les caractères uniques.
Je ne suis pas sûr du type de conflits de plugins auxquels vous faites référence ?
@RGJ Le plugin migratepassword fonctionnera-t-il avec phpBB 3.3 ?
Je suis en train de faire une importation avec un forum phpBB 3.3.8 en ce moment même, et j’importe les mots de passe pour tenter le coup.
Comment pourriez-vous migrer depuis myBB ?
Vous pouvez rechercher myBB et le tag #migration::tag, peut-être trouverez-vous un howto
Ok, merci pour l’info !
Merci pour cette clarification, Richard. Je ne faisais référence à aucun conflit spécifique, juste à la possibilité que quelque chose d’inattendu se produise en territoire inconnu. J’ai fait l’importation délibérément avant d’ajouter des plugins. Surtout, je veux forcer nos membres à mettre à jour leurs mots de passe.
Cette migration s’est vraiment déroulée sans accroc, donc bravo à Gerhard et à tous les autres impliqués pour ce script bien équilibré. J’ai hâte de personnaliser notre nouveau forum.
Oui, il le fera, nous avons récemment ajouté la prise en charge d’Argon2 dans le plugin.
Richard prend en charge le plugin sur son hébergement. Je n’ai jamais entendu parler de problèmes. De nombreux importateurs importent les mots de passe et cela fonctionne tout simplement. J’ai même eu un script d’importation que j’ai écrit pour un autre forum aléatoire qui fonctionnait.