Nous avons essayé et nous rencontrons ces problèmes : tous les messages ont été importés, mais les titres des sujets n’apparaissent pas et les images externes ne s’affichent pas. Le forum SMF2 actuel est : https://forum.mundofotografico.com.br nous essayons de migrer vers Discourse ici : https://discourse.fotografos.online - Tous les sujets et leurs descriptions n’ont pas été transférés, les images ne se chargent pas… aidez-nous s’il vous plaît ! @marcozambi @miligraf @FireAllianceNX @pfaffman
Je commence tout juste le processus de migration SMF et j’importe actuellement des messages dans une instance de test à environ 1000/heure, donc tout va bien jusqu’à présent, à part le script de performance MySQL où MySQL n’a pas apprécié la commande ‘ALTER USER’ pour une raison quelconque. J’ai manuellement exécuté un ‘CREATE USER’ et tout s’est bien passé après cela.
J’ai lu le commentaire sur les utilisateurs supprimés, mais je ne peux pas facilement créer de nouveaux utilisateurs/faux e-mails pour couvrir tous mes utilisateurs supprimés (mon forum fonctionne depuis plus de 20 ans et j’ai probablement plus d’utilisateurs supprimés que d’utilisateurs réels maintenant). Je soupçonne que j’ai 4000 à 5000 utilisateurs supprimés. Tous n’auront pas posté, mais beaucoup l’auront fait, j’ai donc probablement plusieurs centaines d’utilisateurs « manquants ».
Les messages sont importés comme appartenant à « system », ce qui n’est pas vraiment idéal. Je me demandais si ce qui suit fonctionnerait.
- Avant d’importer, créez un utilisateur factice, par exemple « Utilisateur supprimé ».
- Trouvez le numéro d’utilisateur pour « Utilisateur supprimé ».
- Modifiez la ligne « user_id: user_id_from_imported_user_id(message[:id_member]) || -1, » dans smf2.rb et remplacez le ‘-1’ par le numéro d’utilisateur de « Utilisateur supprimé » (je pense que l’utilisateur système est -1 ?).
Est-ce que cela fonctionnerait ? De plus, y a-t-il d’autres endroits dans smf2.rb où je devrais apporter une modification similaire ?
Bonjour, par « supprimés », voulez-vous dire qu’ils sont réellement supprimés de la base de données SMF, ou sont-ils toujours dans la base de données avec leur nom d’utilisateur et leur e-mail et marqués comme suspendus ? Comment les messages de ces utilisateurs « supprimés » s’affichent-ils actuellement dans SMF ?
Je suis au milieu d’une énorme migration de Drupal vers Discourse, également à partir d’un forum de longue date avec des tonnes d’utilisateurs suspendus. Je voulais absolument conserver ces mêmes noms d’utilisateur suspendus et leurs adresses e-mail associées dans Discourse, j’ai donc dû ajouter cette fonction au script d’importation Drupal pour Discourse. Essentiellement, le script importe tous les utilisateurs comme des utilisateurs actifs normaux, et s’ils avaient des messages publiquement visibles, ceux-ci seront également importés comme sur le forum d’origine. Ensuite, à la toute fin du processus, j’ai ajouté une fonction que j’ai tirée d’un autre script d’importation pour parcourir la base de données Drupal et si l’utilisateur était marqué comme suspendu, suspendre également le compte Discourse. Vous pouvez voir le code pour cela dans mon historique de publications ici.
Salut. Les utilisateurs sont effectivement supprimés, c’est-à-dire qu’il n’y a plus d’enregistrement pour eux dans la table smf_member. SMF n’a pas de fonction pour suspendre les utilisateurs. Vous pouvez bannir des utilisateurs, mais cela ne semble pas approprié pour un compte dont l’utilisateur est décédé ou a perdu tout intérêt pour le hobby/forum. Ce n’est pas vraiment correct non plus du point de vue de la protection des données.
Les messages SMF ont deux champs stockés pour chaque enregistrement… le numéro de membre de l’utilisateur, qui est défini sur zéro pour les utilisateurs supprimés, et le nom de l’expéditeur, qui contient le nom d’utilisateur de l’expéditeur. Vous pouvez donc voir quel utilisateur a posté le message, mais il n’y a plus de détails (e-mail, nom complet, etc.) disponibles pour l’utilisateur. Leurs messages portent un marqueur « Invité » lorsqu’ils sont affichés.
Je suppose que je pourrais créer un nouveau compte utilisateur pour chaque utilisateur qui a posté un message dont l’ID de membre est zéro et attribuer une adresse e-mail fictive pour le compte, puis marquer l’utilisateur comme suspendu par la suite. Je pourrais marquer les comptes comme suspendus en fonction du format de l’adresse e-mail fictive si j’utilisais quelque chose d’unique mais d’identifiable. Cela semble un peu étrange dans certains cas… créer des comptes pour des personnes dont je sais qu’elles sont décédées il y a 10 à 15 ans !
J’ai le temps d’y réfléchir cependant… la migration a partiellement fonctionné, mais je dois maintenant comprendre pourquoi les pièces jointes n’ont pas été jointes, pourquoi les liens dans le forum n’ont pas été modifiés et pourquoi les mots de passe des utilisateurs migrés ne fonctionnent pas. Il peut y avoir d’autres problèmes aussi, mais je vais d’abord travailler à résoudre ces problèmes, puis je verrai ce qui d’autre se présente.
Vous voulez dire Postgres ? Je ne suis pas sûr de ce dont il s’agit.
Ce que je ferais, c’est que si l’ID de l’utilisateur est 0, utilisez le nom d’utilisateur pour l’ID. Ensuite, si find_username_by_import_id ne parvient pas à trouver l’utilisateur, créez l’utilisateur, en définissant l’adresse e-mail sur fake_email (c’est une fonction dans base.rb qui génère une adresse e-mail fictive) et le nom d’utilisateur avec le nom d’utilisateur que vous avez. Ensuite, si vous êtes ambitieux, vous pourriez à la fin du script suspendre tous les utilisateurs qui ont @email.invalid dans leur adresse e-mail. Ils ne seront pas actifs, donc je ne pense pas que cela ait beaucoup d’importance si vous ne les suspendez pas.
Une autre façon serait de faire une requête qui générerait d’une manière ou d’une autre une liste de tous les utilisateurs supprimés, puis de les créer avant de commencer à publier, mais cela semble plus difficile.
Si vous voulez créer un utilisateur utilisateur supprimé et que toutes ces publications appartiennent à cet utilisateur au lieu de système, vous pourriez le faire et remplacer simplement le -1 par le numéro d’utilisateur de utilisateur supprimé. Vous pourriez le créer en tant qu’utilisateur régulier ou faire quelque chose de fantaisiste et lui donner un ID d’utilisateur de -2 ou quelque chose comme ça.
Dans certains systèmes, c’est parce que parfois les pièces jointes sont dans le corps de la publication et d’autres fois l’enregistrement de la pièce jointe est dans la base de données.
Avez-vous installé le plugin Prise en charge des hachages de mots de passe migrés après avoir exécuté l’importation (il peut interférer avec l’exécution des importations dans au moins certaines circonstances). SMF2 hache-t-il les mots de passe de la même manière que smf le fait
Désolé, mauvais nom pour le script. C’est le script MySQL auquel il est fait référence dans le premier post
– file: ~/smf2/script_for_mysql_tuning.sql
ALTER USER ‘user’@‘%’ IDENTIFIED WITH mysql_native_password BY ‘pass’;
Merci pour vos suggestions concernant les utilisateurs et en particulier fake_email. Ma première tâche est d’apprendre suffisamment de Ruby pour pouvoir apporter des modifications au script d’importation !
Les pièces jointes SMF2 sont des enregistrements dans la base de données. Après avoir creusé un peu plus, il semble que certaines aient été importées, mais seulement quelques centaines sur des dizaines de milliers. Je continuerai à creuser pour voir si je peux comprendre pourquoi.
Ahhh, c’est probablement ce qui me manque ! Je suis à peu près sûr que SMF2 utilise le même hachage (MD5 salé, si je me souviens bien) que SMF1, donc le plugin résoudra probablement le problème. Je dois faire d’autres importations avant de m’inquiéter trop de la connexion des utilisateurs.
Une autre question me vient à l’esprit. Y a-t-il un moyen de réinitialiser le système pour me permettre de faire une autre importation. J’aurais dû faire une sauvegarde avant de commencer, mais j’ai oublié ![]()
Oh. Vous voulez dire juste configurer MySQL. Je vois.
Si vous connaissez d’autres langages, vous pouvez probablement vous débrouiller.
J’ai écrit plusieurs importateurs avant de faire quoi que ce soit comme apprendre Ruby. ![]()
Voici une façon de supprimer et de créer une nouvelle base de données Discourse.
sv stop unicorn;DISABLE_DATABASE_ENVIRONMENT_CHECK=1 IMPORT=1 rake db:drop db:create db:migrate; sv start unicorn
Si vous vous souvenez de faire une sauvegarde, cela peut être un peu plus rapide. Peut-être.
Une autre astuce, une fois que vous avez configuré les utilisateurs, consiste à arrêter le script après l’importation des utilisateurs et à faire une sauvegarde à ce moment-là. Cela vous permettra de déboguer l’importation des posts sans avoir à importer à nouveau tous les utilisateurs.
Je connais quelques langues. J’ai écrit mon premier programme en 1976 en code machine binaire sur un Intel 4004. Je commence à comprendre smf2.rb avec un peu de DuckDuckGo pour comprendre certaines des structures de code qui me sont nouvelles.
Merci pour la méthode de suppression/création de base de données. Il est temps de recommencer et de voir si je peux apporter quelques changements progressifs à l’importateur pour mes données.
J’ai réussi à modifier l’importateur pour créer des comptes factices avec une fausse adresse e-mail pour les utilisateurs supprimés, et les comptes factices possèdent leurs publications correctes, c’est donc un bon début.
J’essaie de comprendre les pièces jointes ensuite car je n’en vois aucune sur les publications que j’ai importées jusqu’à présent (et il devrait y en avoir).
Si je crée un message normalement via la page Web Discourse, j’obtiens un enregistrement dans la table posts (id=4346), deux enregistrements dans la table uploads (ids=403 et 404), quatre enregistrements dans upload_references (403/Draft/4, 403/Post/4346, 404/Draft/4, 404/Post/4346). Je vois également 403 dans le champ image_upload_id pour le post 4346 et du HTML faisant référence aux deux téléchargements dans le champ posts/cooked.
Pour les publications importées, j’obtiens un enregistrement dans la table posts pour chaque message SMF importé et un enregistrement dans la table uploads pour chaque pièce jointe associée à un message SMF importé. Les enregistrements de la table uploads font référence à des fichiers sur disque qui contiennent les images correctes, donc cette partie fonctionne bien. Cependant, je n’obtiens aucun enregistrement upload_references pour les images téléchargées ni aucun des identifiants de téléchargement dans le champ image_upload_id de la table posts.
Je suppose que je dois essayer de faire créer les enregistrements upload_references et de remplir les champs posts-image_upload_id et cooked, mais je voulais d’abord vérifier s’il n’y a pas une autre façon d’associer les téléchargements aux publications qui est utilisée (ou tentée d’être utilisée) par l’importateur ?
Il semble que vous deviez ajouter une référence à l’hôte/téléchargement dans raw. Il existe une fonction qui générera un lien pour vous. Je ne me souviens plus de son nom. Je pense qu’elle se trouve dans le modèle de téléchargements, mais il pourrait être plus facile de la trouver dans un autre script d’importation si vous ne savez pas ce qu’est un modèle.
Je faisais des progrès en ajustant le script d’importation pour l’adapter aux particularités de mon forum, mais je me suis arrêté net il y a quelques jours. Après la dernière mise à jour de Discourse beta, je ne peux plus construire le conteneur d’importation. J’obtiens…
> 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.
J’ai vu les publications concernant l’expiration de la clé yarn et je l’ai corrigée. Cela empêchait l’installation du paquet libmariadb-dev, mais j’ai effectué une installation manuelle du paquet qui a fonctionné correctement. La reconstruction de l’importation ne fonctionne toujours pas avec le modèle d’importation mysql activé, même après avoir installé manuellement le paquet MariaDB.
J’ai construit un nouveau serveur et j’ai commencé avec une nouvelle installation de Discourse juste pour éviter tout problème potentiel avec le serveur/l’installation précédente. Le nouveau serveur donne la même erreur que l’ancien.
Je n’ai plus d’idées sur quoi essayer ensuite, donc j’accepterai toutes les suggestions !
Voir Apt-get update fails inside container yarn repo not signed - #5 by pfaffman. Vous devrez modifier le modèle mysql.
Merci de m’avoir mis sur la bonne voie. Je vois maintenant ce que j’ai fait de mal !
Nous commençons par la migration test d’un forum SMF 2 (v2.0.15 pour être précis) et l’un des premiers problèmes qui est apparu est un souci lorsque les catégories ont une esperluette dans leur nom :
Les titres de sujets avec la même chose semblent être corrects :

Jusqu’à présent, il semble que l’esperluette soit le seul caractère problématique et que, par exemple, les umlauts allemands soient corrects :
Nous sommes probablement également touchés par les problèmes signalés ici dans le fil (utilisateurs supprimés, pièces jointes, liens dans le forum), mais l’importation est toujours en cours, je mettrai donc à jour une fois qu’elle sera terminée.
À cet égard, je me demande si la vitesse d’importation est vraiment censée être aussi lente. Nous importons actuellement à 1750 éléments/min (initialement, c’était un peu plus proche de 2000 éléments/min) sur une machine AMD Ryzen 5 3600 avec 64 Go de RAM (Hetzner, Ubuntu 22.04), ce qui porte l’ensemble de la migration à environ 3 jours.
C’est une assez bonne vitesse.
J’imagine que les problèmes signalés existent toujours, bien qu’un nombre surprenant de choses soient propres à un forum. Si vous souhaitez que certaines choses soient corrigées et que vous avez un budget, je serais heureux de vous aider.
Merci ! Je reviendrai vers vous une fois que les choses seront plus concrètes.
Pour l’instant, nous (une petite organisation à but non lucratif axée sur les jeux de rôle sur table et les loisirs associés) sommes en phase d’évaluation - il y a un consensus sur le fait que nous voulons un nouveau logiciel et que Discourse est, jusqu’à présent, l’option favorite. Mais nous devrons rassembler toutes les tâches à accomplir (migration, nouveau thème, nouveaux plugins/composants de thème si nécessaire) et voir si nous pouvons tout intégrer dans notre budget.
Y a-t-il une raison particulière pour cette étape ?
D’après ce que je peux voir en relisant attentivement le message initial, ce fichier smf2.rb n’est pas modifié/patché ?
Et si smf2.rb se trouve sur l’hôte dans (par exemple) /var/discourse/smf2 et que vous avez configuré votre montage de volume à l’étape 2 en conséquence, il est de toute façon monté à l’intérieur de l’invité à /shared/smf2.
Je ne comprends pas la nécessité de le copier comme une étape distincte. Mais comprendre cela pourrait être la clé pour déterminer pourquoi 95 % des pièces jointes ne sont pas correctement trouvées par le script…
Il semble que vous ayez raison concernant le (manque de nécessité) de le copier. Peut-être que l’auteur l’a modifié et que ses modifications ont été ultérieurement intégrées au cœur du système.
Si vous obtenez 5% et non 0% des pièces jointes, alors il semble y avoir un problème avec le script.
Dans certains systèmes, il existe deux façons de joindre des fichiers, l’une en le mentionnant dans le fichier (donc il est dans le texte brut du message et est traité ainsi) et une autre en l’attachant au message dans certaines métadonnées/tables. Je suppose que vous avez 95% dans votre base de données d’une manière et que le script fait l’autre.
Mais il semble qu’il essaie peut-être les deux méthodes ? Vous devrez trouver un message qui devrait avoir une pièce jointe, regarder dans la base de données et le système de fichiers pour voir comment elle est stockée, puis regarder le code pour voir pourquoi il ne la récupère pas.
Merci @pfaffman, c’est rassurant ! Je pensais que c’était probablement le cas, mais comme j’ai tellement de problèmes avec cette importation, j’ai douté de mes connaissances et de mes compétences à tous les niveaux !
Merci pour ces conseils, tout est apprécié @pfaffman - c’est une nouvelle tentative, très retardée, sur le même forum sur lequel je travaillais l’année dernière. C’est un travail bénévole, mais je pourrais vous solliciter à nouveau si vous avez le temps.
C’est un très vieux forum SMF2 qui a des pièces jointes sous deux formes :
\u003cid\u003e_\u003cNom_du_fichier_SANS_casse_règles_jpg\u003e_\u003c32caractèresprobablementhashMD50fsom4thing\u003e\u003cid\u003e_\u003c40caractèresprobablementhashSHA10fsom4thing\u003e
J’essaie toujours de comprendre s’il y a un schéma dans les échecs.
Ma supposition (sans regarder le code !) est que l’un de ceux-ci est ce que le script fait et l’autre non (probablement l’un est l’ancienne méthode, donc les nouveaux messages utilisent l’autre méthode, mais il n’est pas revenu en arrière pour corriger ceux qui utilisaient l’autre méthode).
Regardez donc convert_message_body et les champs de la table des pièces jointes. Peut-être sont-ils passés de MD5 à SHA1 ou vice versa pour une raison quelconque.
Comme je l’ai dit, il se pourrait qu’une version de ceux-ci fasse référence au téléchargement au lieu de le lier dans la table, donc vous feriez un gsub pour rechercher ce modèle, et ensuite s’il correspondait, vous obtiendriez la clé, la rechercheriez dans la table, puis create_upload avec ce fichier. .
J’espère que cela suffira pour vous lancer, mais contactez-moi si vous souhaitez plus d’aide que je ne peux vous en donner ici.

