Merci pour ces informations précieuses !

J’ai une autre question concernant la requête SQL qui sélectionne les utilisateurs de vBulletin.

Lorsque j’ai importé mon ancien forum phpBB vers Discourse il y a 3 ans, il y avait environ 20 000 utilisateurs. Évidemment, la plupart de ces comptes étaient inutilisés. Au cours de ces trois années, Discourse a effectué son propre nettoyage des utilisateurs inactifs, et nous avons maintenant un chiffre plus réaliste de 3 000 membres.

Lorsque j’ai importé mes 180 000 utilisateurs de vBulletin et demandé à Discourse d’effectuer son nettoyage de manière agressive, il me restait 27 000 utilisateurs, ce qui semble raisonnable.

Sur mon vBulletin, puisque :

1. Tous les messages postés par des utilisateurs sur les profils d’autres utilisateurs sont importés dans Discourse sous forme de sujets sans catégorie et sans titre, qui n’ajoutent rien d’autre que du bruit inutile, et
2. La grande majorité des utilisateurs ayant posté uniquement sur les profils d’autres utilisateurs semblent être des spammeurs,
   je souhaiterais effectuer ce nettoyage pendant l’importation et non après.

Je ne comprends pas tout de la base de données vBulletin, qui est un peu confuse avec son système de nœuds, mais je souhaite importer uniquement les utilisateurs qui ont publié au moins 1 sujet ou réponse.
Il me semble que les sujets et les réponses remplissent le champ lastpostid dans la table utilisateur de vBulletin, mais les publications publiques sur les profils ne le font pas.

Oui, je compte modifier

  SELECT u.userid, u.username, u.homepage, u.usertitle, u.usergroupid, u.joindate, u.email
    CASE WHEN u.scheme='blowfish:10' THEN token
         WHEN u.scheme='legacy' THEN REPLACE(token, ' ', ':')
    END AS password,
    IF(ug.title = 'Administrators', 1, 0) AS admin
    FROM #{DB_PREFIX}user u
    LEFT JOIN #{DB_PREFIX}usergroup ug ON ug.usergroupid = u.usergroupid
ORDER BY userid
   LIMIT #{BATCH_SIZE}
  OFFSET #{offset}

en :

  SELECT u.userid, u.username, u.homepage, u.usertitle, u.usergroupid, u.joindate, u.email, u.lastpost
    CASE WHEN u.scheme='blowfish:10' THEN token
         WHEN u.scheme='legacy' THEN REPLACE(token, ' ', ':')
    END AS password,
    IF(ug.title = 'Administrators', 1, 0) AS admin
    FROM #{DB_PREFIX}user u
    LEFT JOIN #{DB_PREFIX}usergroup ug ON ug.usergroupid = u.usergroupid
    WHERE u.lastpost > 0
ORDER BY userid
   LIMIT #{BATCH_SIZE}
  OFFSET #{offset}

J’ajoute simplement WHERE u.lastpost > 0.

Un comptage avec cette requête me donne 25 000 utilisateurs, comparé aux 27 000 utilisateurs actifs de mon importation précédente, après un nettoyage Discourse mais avec toujours ces sujets sans titre (anciennes publications publiques sur les profils). Cela signifierait qu’environ 2 000 utilisateurs auraient posté uniquement sur les profils d’autres utilisateurs, ce qui n’est pas un nombre absurde.

Pensez-vous que mon raisonnement est correct et que l’ajout de WHERE u.lastpost > 0 nettoiera proprement ma base d’utilisateurs sans aucun effet néfaste ?

Cela dépend de l’historique de votre base de données. Si elle a été migrée de phpBB vers vBulletin ou si elle a subi de nombreuses mises à jour de vBulletin, alors cette logique pourrait être erronée.

Le mieux que vous puissiez faire est de vérifier votre raisonnement en exécutant davantage de requêtes, par exemple en listant tous les messages publiés par les utilisateurs sans lastpost.

De plus, si vous avez des plugins comme « likes » ou « votes », vous risquez de supprimer des utilisateurs que vous ne devriez pas supprimer.

Ma stratégie consiste à être très prudent lorsqu’il s’agit de supprimer ou d’omettre des éléments. Le stockage est peu coûteux.

Merci, je ferai comme tu le dis, je préfère être prudent.
Je laisserai Discourse faire son propre nettoyage au fil du temps.

Je passe des jours à ajouter des expressions régulières de nettoyage de messages personnalisés dans ton script de migration car le forum est très ancien et a été migré depuis phpBB avant vBulletin, donc beaucoup de choses devaient être prises en charge. Mais je pense et j’espère que je suis proche de la finalisation.

Je ne connais pas vraiment vBulletin, mais le forum sur lequel je travaille utilisait vBulletin 5.6 et certaines images externes que j’avais postées utilisaient cette syntaxe dans la base de données vBulletin :
[IMG2=JSON]{"data-align":"none","data-size":"full","src":"https:\/\/forum.monocycle.info\/uploads\/default\/original\/2X\/3\/396192845ba93e7df2a6109a2608072efa21ee32.jpeg"}[/IMG2]
Je ne sais pas si c’est quelque chose qui a été « oublié » dans ton script, ou si l’administrateur du forum utilisait un plugin générant ces balises img2.

Quoi qu’il en soit, je les ai corrigées avec ce code :

    raw = raw.gsub(/\[img2=json\].+?(http.+?).}\[\/img2\]/i) {"\n#{$1}\n"}

J’ai cependant une question : Discourse rebakera-t-il automatiquement les messages importés au fil du temps ? Si oui, commencera-t-il par les messages les plus récents ?

Salut à nouveau,

Mon forum compte environ 1000 tags, mais nous ne les utiliserons probablement pas sur Discourse. De plus, ces tags sont probablement un vrai fouillis. Puis-je simplement commenter cette ligne dans l’importateur :

    import_tags

Ou cela pourrait-il causer des dommages collatéraux ?

Vous pouvez l’encadrer sans risque.

Est-il sûr de ne pas attendre que Sidekiq termine ses tâches après avoir importé quelque chose ?

J’ai importé mes utilisateurs et voici l’état actuel de Sidekiq.

image1182×324 27.3 KB

Que deviennent ces tâches si je crée une sauvegarde et que je la restaure sur un forum de production ?

Non, bien qu’un recalcul complet recrée la plupart de ces tâches, je vous recommande absolument d’attendre.

Elles continueront de s’exécuter… sur l’instance d’importation.
Elles ne seront pas incluses dans la sauvegarde ni transférées vers le forum de production.

Merci !

À cause de certains messages d’erreur lors des restaurations de sauvegardes (qui n’empêchent pas la restauration de se terminer ni le forum de fonctionner), je me demandais si cela pouvait être dû au fait que je n’avais pas attendu que Sidekiq termine son travail.

J’ai lancé une nouvelle importation depuis vBulletin : j’ai uniquement importé les groupes et 30 000 utilisateurs sur mon Discourse de développement, attendu quelques dizaines de minutes, puis créé une sauvegarde que j’ai restaurée sur une installation basée sur Docker. La restauration a fonctionné, mais les journaux affichent ces erreurs :

ActiveRecord::StatementInvalid (PG::UndefinedTable: ERROR: relation "users" does not exist LINE 1: SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1 ^ ) lib/a
10:03 pm
7
ActiveRecord::StatementInvalid (PG::UndefinedTable: ERROR: relation "user_auth_tokens" does not exist LINE 1: SELECT "user_auth_tokens".* FROM "user_auth_tokens" WHERE ((...

Elles sont incohérentes, et les erreurs de relation varient d’une sauvegarde à l’autre.
Je n’arrive pas à comprendre d’où elles proviennent.

TL;DR Je ne pense pas que ces erreurs soient liées à l’importation de quelque manière que ce soit.

J’ai déjà vu cela auparavant ; je pense qu’il s’agit d’une condition de course qui se produit parce que la base de données est consultée pendant la restauration de la sauvegarde.

Cela peut être dû au trafic régulier arrivant sur votre serveur ou à un processus Sidekiq qui n’a pas été mis en pause. Dans les deux cas, cela est inoffensif. Si j’étais vous, j’ignorerais complètement toutes les erreurs PG qui surviennent avant que la restauration ne soit entièrement terminée.

C’est rassurant !

Le problème, c’est que non seulement les messages eux-mêmes m’inquiètent un peu, mais ils le sont aussi parce que :

1. ils apparaissent pour chaque sauvegarde (ou presque ? ) que j’ai créée depuis le début de mon import, que je restaure la sauvegarde sur un forum de développement local ou une installation Docker en ligne.
2. ils empêchent le journal de restauration (dans l’interface de sauvegarde de Discourse) de continuer à être mis à jour dans l’interface de Discourse pendant la restauration : il reste bloqué sur « décompression de l’archive » (ou « Création des fonctions manquantes dans le schéma discourse_functions… » s’il s’agit d’une sauvegarde sans fichiers joints).
   On dirait qu’un crash s’est produit, mais si j’attends, après un certain temps, je suis toujours correctement et automatiquement déconnecté, et lorsque je me reconnecte, l’import semble avoir bien fonctionné malgré ces messages d’erreur.

Puisque le forum fonctionne (à part l’édition de catégorie qui entraîne une erreur 502 que j’ai décrite dans un autre fil), j’ai simplement peur que le forum fonctionne… jusqu’à ce qu’il ne fonctionne plus pour une raison quelconque dans quelques semaines/mois/années à cause de quelque chose que je n’aurais pas compris au départ, ce que je ne veux vraiment pas voir arriver, surtout depuis que je travaille quotidiennement sur cet import depuis un mois et plus.

Bref, merci pour votre aide, elle est très appréciée. Je consacre beaucoup d’énergie à ce travail d’import non rémunéré pour une grande communauté, et avoir des personnes qui répondent à mes questions est toujours un soulagement.

Tout d’abord, merci d’avoir posté ceci. Je viens d’essayer d’importer vBulletin 3.7.x. J’ai suivi toutes les étapes, mais lorsque j’ai exécuté le script d’importation, il indique qu’il ne peut pas se connecter, alors que je peux me connecter. Des idées ?

root@uat-app:/var/www/discourse# export DB_NAME="vb4"
root@uat-app:/var/www/discourse# export DB_USER="root"
root@uat-app:/var/www/discourse# export DB_PW="1234"
root@uat-app:/var/www/discourse# export TABLE_PREFIX="vbulletin"
root@uat-app:/var/www/discourse# export ATTACHMENT_DIR='/shared/vbulletin'
root@uat-app:/var/www/discourse# export TIMEZONE="America/Vancouver"
root@uat-app:/var/www/discourse# su discourse -c 'bundle exec ruby script/import_scripts/vbulletin.rb'
root:1234@localhost veut vb4
Chargement des groupes existants...
Chargement des utilisateurs existants...
Chargement des catégories existantes...
Chargement des messages existants...
Chargement des sujets existants...
==================================================
Accès refusé pour l'utilisateur 'root'@'localhost'
Impossible de se connecter à la base de données.

Nom d'hôte : localhost
Nom d'utilisateur : root
Mot de passe : 1234
Base de données : vb4

Modifiez le script ou définissez ces variables d'environnement :

export DB_HOST="localhost"
export DB_NAME="vbulletin"
export DB_PW=""
export DB_USER="root"
export TABLE_PREFIX="vb_"
export ATTACHMENT_DIR '/chemin/vers/votre/dossier/joint'

Sortie.

Ci-dessous, vous pouvez voir que je parviens à me connecter à la base de données en utilisant les mêmes identifiants et j’ai validé le nom de la base de données et le préfixe de table.

root@uat-app:/var/www/discourse# mysql -uroot -p1234 -hlocalhost
Bienvenue sur le moniteur MariaDB. Les commandes se terminent par ; ou \g.
Votre ID de connexion MariaDB est 70
Version du serveur : 10.3.25-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab et autres.

Tapez 'help;' ou '\h' pour obtenir de l'aide. Tapez '\c' pour effacer la déclaration d'entrée actuelle.

MariaDB [(none)]> use vb4;
Lecture des informations de table pour compléter les noms de table et de colonne
Vous pouvez désactiver cette fonctionnalité pour un démarrage plus rapide avec -A

Base de données changée
MariaDB [vb4]> select * from information_schema.tables where table_schema = 'vb4' and table_name = 'vbulletinpost'
    -> ;
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
| TABLE_CATALOG | TABLE_SCHEMA | TABLE_NAME    | TABLE_TYPE | ENGINE | VERSION | ROW_FORMAT | TABLE_ROWS | AVG_ROW_LENGTH | DATA_LENGTH | MAX_DATA_LENGTH | INDEX_LENGTH | DATA_FREE | AUTO_INCREMENT | CREATE_TIME         | UPDATE_TIME         | CHECK_TIME          | TABLE_COLLATION   | CHECKSUM | CREATE_OPTIONS | TABLE_COMMENT | MAX_INDEX_LENGTH   | TEMPORARY |
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
| def           | vb4          | vbulletinpost | BASE TABLE | MyISAM |      10 | Dynamic    |    1037509 |            356 |   370191960 | 281474976710655 |     53087232 |         0 |        1046506 | 2020-11-14 14:27:01 | 2020-11-14 14:27:28 | 2020-11-14 14:27:32 | latin1_swedish_ci |     NULL |                |               | 288230376151710720 | N         |
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
1 ligne dans l'ensemble (0,001 sec)

MariaDB [vb4]>

De plus, j’ai exporté les avatars vers /admincp/avatar.php?do=storage et exporté les avatars dans trois dossiers différents comme ceci :

/shared/vbulletin/signaturepics/
/shared/vbulletin/customprofilepics/
/shared/vbulletin/customavatars/

Dois-je alors spécifier le dossier parent comme ceci ? Ou dois-je prendre le contenu des trois dossiers et les mettre dans un seul ?

export ATTACHMENT_DIR='/shared/vbulletin'

Mon seul soupçon est que votre mot de passe contient peut-être des caractères spéciaux ?

En fait, ce n’est rien d’autre que des caractères alphabétiques et numériques. Quoi qu’il en soit, j’ai essayé à nouveau et confirmé que cela ne fonctionne pas tant que je ne définis pas explicitement le mot de passe. J’ai également remarqué que les instructions doivent être mises à jour, alors je copie ici ce qui fonctionne pour moi.

Les instructions doivent être mises à jour. Voici ce qui fonctionne pour moi à partir de novembre 2020. Notez qu’il est en effet préférable d’exécuter cette importation via screen, car l’importation peut prendre plusieurs heures, et l’utilisation de nohup risque de ne pas être utile car le script d’importation mettra constamment à jour le nombre d’éléments importés, ce qui risque de rendre le fichier stdout très volumineux.

Installer la base de données pour héberger les données vBulletin

Télécharger les derniers paquets

Notez que MySQL n’est plus disponible sauf si le dépôt Oracle MySQL est explicitement ajouté à la liste des dépôts. MariaDB a remplacé MySQL.

root@uat-app:~# apt-get update
root@uat-app:~# apt-get install libmariadb-dev
root@uat-app:~# apt-get install default-mysql-server

Démarrer la base de données

root@uat-app:~# service mysql status
[info] MariaDB est arrêté..
root@uat-app:~#
root@uat-app:~# service mysql start
[ ok ] Démarrage du serveur de base de données MariaDB : mysqld.
root@uat-app:~# service mysql status
[info] /usr/bin/mysqladmin Ver 9.1 Distrib 10.3.25-MariaDB, pour debian-linux-gnu sur x86_64
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab et autres.

Version du serveur 10.3.25-MariaDB-0+deb10u1
Version du protocole 10
Connexion via socket UNIX sur localhost
Socket UNIX /var/run/mysqld/mysqld.sock
Temps de fonctionnement : 4 sec

Threads : 7 Questions : 461 Requêtes lentes : 0 Ouvertures : 177 Rafraîchissements de tables : 1 Tables ouvertes : 31 Requêtes par seconde en moyenne : 115.250.

Installer les Gems pour la connectivité de la base de données

Ce qui suit montre que le dernier « bundle » n’apprécie pas certains des drapeaux dans les instructions originales et qu’il est nécessaire de désactiver le mode « deployment ».

root@uat-app:~# echo "gem 'mysql2', require: false" >> /var/www/discourse/Gemfile

root@uat-app:~# echo "gem 'php_serialize', require: false" >> /var/www/discourse/Gemfile

root@uat-app:~# cd /var/www/discourse
root@uat-app:/var/www/discourse# su discourse -c 'bundle install --no-deployment --without test --without development --path vendor/bundle'
[DEPRECATED] Le drapeau `--path` est déprécié car il dépend d'être mémorisé lors des invocations de bundler, ce que bundler ne fera plus dans les versions futures. Veuillez utiliser à la place `bundle config set path 'vendor/bundle'` et arrêter d'utiliser ce drapeau.
[DEPRECATED] Le drapeau `--without` est déprécié car il dépend d'être mémorisé lors des invocations de bundler, ce que bundler ne fera plus dans les versions futures. Veuillez utiliser à la place `bundle config set without 'development'` et arrêter d'utiliser ce drapeau.
Vous essayez d'installer en mode déploiement après avoir modifié
votre Gemfile. Exécutez `bundle install` ailleurs et ajoutez le
Gemfile.lock mis à jour au contrôle de version.

Si c'est une machine de développement, supprimez le gel du fichier /var/www/discourse/Gemfile en exécutant `bundle config unset deployment`.

Les dépendances dans votre gemfile ont changé

Vous avez ajouté au Gemfile :
* mysql2
* php_serialize

Mettre à jour la configuration et relancer l’installation

Vérifier via l’interface CLI

La vérification de la configuration a confirmé qu’elle est définie en mode « deployment ».

root@uat-app:/var/www/discourse# bundle config list
Les paramètres sont listés par ordre de priorité. La valeur supérieure sera utilisée.
deployment
Défini pour votre application locale (/var/www/discourse/.bundle/config) : true

jobs
Défini pour votre application locale (/var/www/discourse/.bundle/config) : 4

retry
Défini pour votre application locale (/var/www/discourse/.bundle/config) : 3

path
Défini pour votre application locale (/var/www/discourse/.bundle/config) : "vendor/bundle"

without
Défini pour votre application locale (/var/www/discourse/.bundle/config) : [:development, :test]

Vérifier en inspectant le fichier de configuration

Ce qui suit effectue la même vérification en inspectant le fichier de configuration.

root@uat-app:/var/www/discourse# cat /var/www/discourse/.bundle/config
---
BUNDLE_DEPLOYMENT: "true"
BUNDLE_JOBS: "4"
BUNDLE_RETRY: "3"
BUNDLE_PATH: "vendor/bundle"
BUNDLE_WITHOUT: "development:test"

Mettre à jour la configuration

root@uat-app:/var/www/discourse# bundle config set path 'vendor/bundle'
Votre application a défini le chemin vers "vendor/bundle". Cela remplacera la valeur globale que vous définissez actuellement.
root@uat-app:/var/www/discourse# bundle config set without 'development:test'
Votre application a défini sans "development:test". Cela remplacera la valeur globale que vous définissez actuellement.
root@uat-app:/var/www/discourse# bundle config unset deployment

Valider à nouveau la configuration

root@uat-app:/var/www/discourse# bundle config list
Les paramètres sont listés par ordre de priorité. La valeur supérieure sera utilisée.
path
Défini pour votre application locale (/var/www/discourse/.bundle/config) : "vendor/bundle"
Défini pour l'utilisateur actuel (/root/.bundle/config) : "vendor/bundle"

without
Défini pour votre application locale (/var/www/discourse/.bundle/config) : [:development, :test]
Défini pour l'utilisateur actuel (/root/.bundle/config) : [:development, :test]

jobs
Défini pour votre application locale (/var/www/discourse/.bundle/config) : 4

retry
Défini pour votre application locale (/var/www/discourse/.bundle/config) : 3

Tenter à nouveau l’installation

Exécutez à nouveau l’installation pour les Gems et quittez le conteneur.

root@uat-app:/var/www/discourse# su discourse -c 'bundle install'
...........
Bundle terminé ! 125 dépendances Gemfile, 163 gems maintenant installées.
Les gems dans les groupes development et test n'ont pas été installées.
Les gems regroupées sont installées dans `./vendor/bundle`
root@uat-app:/var/www/discourse# exit

Créer un répertoire pour les données vBulletin

Créer le répertoire

[root@uat standalone]# pwd
/var/discourse/shared/standalone
[root@uat standalone]# mkdir vbulletin

Copier la base de données vBulletin

[root@uat standalone]# scp <login user>@<vbulletin server IP>:/home/backup/vbulletin/vbulletin-2020-11-14-03:30:01.sql.bz2 ./vbulletin/.

Décompresser la base de données vBulletin

[root@uat containers]# docker exec -it app bash
root@uat-app:/# cd /shared/vbulletin
root@uat-app:/shared/vbulletin# bunzip2 vbulletin-2020-11-14-03\:30\:01.sql.bz2

Configurer la source de données

Créer la base de données vb4

root@uat-app:/shared/vbulletin# mysql -uroot -p -e 'CREATE DATABASE vb4'
Entrez le mot de passe :

Importer vBulletin dans MariaDB

root@uat-app:/shared/vbulletin# mysql -uroot -p vb4 < vbulletin-2020-11-14-03\:30\:01.sql
Entrez le mot de passe :

Décompresser les archives de profil

[root@uat vbulletin]# tar xvfz signaturepics.tar.gz
[root@uat vbulletin]# tar xvfz customavatars.tar.gz
[root@uat vbulletin]# tar xvfz customprofilepics.tar.gz

Mettre à jour le mot de passe racine de la base de données

root@uat-app:/var/www/discourse# mysql -uroot -p
Entrez le mot de passe :
Bienvenue sur le moniteur MariaDB. Les commandes se terminent par ; ou \g.
Votre ID de connexion MariaDB est 77
Version du serveur : 10.3.25-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab et autres.

Tapez 'help;' ou '\h' pour l'aide. Tapez '\c' pour effacer la déclaration d'entrée actuelle.

MariaDB [(none)]> ALTER USER 'root'@'localhost' IDENTIFIED BY '1234';
Requête OK, 0 lignes affectées (0.001 sec)

MariaDB [(none)]> quit
Bye

Importer dans Discourse

Définir les détails de connexion de la source de données

[root@uat vbulletin]# export DB_NAME="vb4"
[root@uat vbulletin]# export DB_USER="root"
[root@uat vbulletin]# export DB_PW="1234"
[root@uat vbulletin]# export TABLE_PREFIX="vbulletin"
[root@uat vbulletin]# export ATTACHMENT_DIR='/shared/vbulletin'
[root@uat vbulletin]# export TIMEZONE="America/Vancouver"
[root@uat vbulletin]# cd /var/www/discourse
root@uat-app:/var/www/discourse# su discourse -c 'bundle exec ruby script/import_scripts/vbulletin.rb'
root:1234@localhost souhaite vb4
Chargement des groupes existants...
Chargement des utilisateurs existants...
Chargement des catégories existantes...
Chargement des messages existants...
Chargement des sujets existants...

importation des groupes...
15 / 15 (100.0%) [3272 éléments/min] n]
importation des utilisateurs
117 / 11033 ( 1.1%) [145 éléments/min] in]

Donc, le problème avec votre connexion initiale à la base de données était dû au mélange de bibliothèques ?

Je ne pense pas. J’ai littéralement changé le mot de passe explicitement et cela a pu s’exécuter. Je rencontre un problème lors de l’importation des messages privés maintenant. Je vois beaucoup de ceci. Une idée de ce que c’est ?

importation des messages privés...
      139 / 177409 (  0,1 %)  [399 éléments/min]  l'ID de l'un des participants est nil -- [nil, 270]
pm-149 n'a pas de cible (a:1:{i:486;s:5:"TonyN";})
      364 / 177409 (  0,2 %)  [418 éléments/min]  l'ID de l'un des participants est nil -- [nil, 276]
pm-420 n'a pas de cible (a:1:{i:623;s:14:"the other side";})
      571 / 177409 (  0,3 %)  [414 éléments/min]  l'ID de l'un des participants est nil -- [nil, 445]
pm-702 n'a pas de cible (a:1:{i:767;s:6:"greatg";})
      572 / 177409 (  0,3 %)  [414 éléments/min]  l'ID de l'un des participants est nil -- [nil, 445]
      605 / 177409 (  0,3 %)  [416 éléments/min]  l'ID de l'un des participants est nil -- [nil, 461]

Soit ces utilisateurs n’ont pas été importés pour une raison quelconque (une adresse e-mail manquante en était souvent la cause, mais cela devrait être résolu maintenant), soit, pour une autre raison, le code qui recherche les noms d’utilisateurs importés ne fonctionne pas (la casse du nom d’utilisateur, peut-être ?).

@pfaffman oui, c’est ce que cela semble indiquer, bien que certains détails ne soient pas clairs. Regardons le premier exemple par exemple.

1. Que signifie pm-149 ?
2. Pour a:1:{i:486;s:5:"TonyN";}, le texte “TonyN” ressemble à un nom d’utilisateur, mais qu’en est-il des autres chiffres ?
3. Et [nil, 270] ? Que signifie 270 ?

Si je comprends de quoi il se plaint, je peux au moins essayer de consulter la base de données pour voir s’il y a des problèmes de données. Mais je ne suis pas sûr de ce que ces éléments signifient vraiment.

BTW, j’ai aussi remarqué que tous les forums importés ont des permissions pour tout le monde. Cela signifie que les forums qui étaient réservés aux modérateurs ont été rendus visibles pour tous. Y a-t-il un moyen de contrôler cela ?

Désolé. Je ne m’en souviens pas assez pour l’expliquer. C’est tout l’aide gratuite que je peux offrir sur ce sujet.

Bien sûr. Voir Understanding groups and category permissions

Certains importateurs s’efforcent d’importer des groupes, mais peu savent comment appliquer ces permissions aux catégories importées. Vous devrez les corriger manuellement.

En suivant les instructions de @titusc, je semble rencontrer des problèmes lors de l’importation de la base de données…

root@DO-Discourse-app:/shared/vbulletin# mysql -uroot -p vb4 < CC12-Sat-Full-Backup.sql
Entrez le mot de passe : 
ERREUR 1265 (01000) à la ligne 4928 : Données tronquées pour la colonne 'method' à la ligne 1
root@DO-Discourse-app:/shared/vbulletin#

Des suggestions sur ce qu’il recherche ?

N/M Ce sont des erreurs dans la base de données d’origine…