Migrer un forum du plugin WordPress bbPress vers Discourse

J’ai récemment effectué avec succès une migration de base de données bbPress en utilisant le script de migration intégré de Discourse. Je vais maintenant le partager sous forme de tutoriel étape par étape.

Note : Ce tutoriel concerne le plugin bbPress et non l’ancienne version autonome de bbPress.

Quelles données peuvent être importées ?

• Utilisateurs (y compris les utilisateurs anonymes)
• Catégories
• Sujets
• Messages
• Messages privés (via BuddyPress)
• Pièces jointes
• Liens permanents (permalinks)

Avant de commencer la migration, configurez un environnement de développement sur votre machine (ou dans une machine virtuelle) et exécutez l’importation depuis cet environnement plutôt que dans le conteneur Docker. Lorsque j’ai essayé de l’exécuter dans un conteneur Docker, j’ai rencontré une erreur peer authentication failed. Je vous recommande donc vivement d’utiliser une machine de développement. Consultez le guide d’installation pour macOS ou Ubuntu / Debian en mode développement.

Discourse nécessite Ruby 3.4+. Vous pouvez vérifier votre version de Ruby avec :

ruby -v

Nous devons maintenant installer la dépendance libmysqlclient-dev afin de pouvoir utiliser le gem mysql2.

sudo apt-get install libmysqlclient-dev

Après l’installation réussie, accédez au chemin d’installation de votre environnement de développement Discourse (généralement ~/discourse).

cd ~/discourse

Configuration de la connexion à la base de données

Le script d’importation bbPress lit tous les paramètres de connexion à la base de données depuis des variables d’environnement. Vous n’avez pas besoin de modifier le fichier du script. Les variables d’environnement suivantes sont prises en charge :

Si vous migrez votre base de données depuis localhost, vous n’avez généralement besoin de définir que le nom de la base de données :

IMPORT=1 bundle && IMPORT=1 BBPRESS_DB="my_bbpress" bundle exec ruby script/import_scripts/bbpress.rb

Si vous migrez votre base de données depuis un serveur externe, vous devrez également définir l’hôte, le nom d’utilisateur et le mot de passe :

IMPORT=1 bundle && IMPORT=1 BBPRESS_HOST="REMOTE_HOST_NAME" BBPRESS_USER="DB_USERNAME" BBPRESS_PW="MY_SECURE_PASSWORD" BBPRESS_DB="DB_NAME" bundle exec ruby script/import_scripts/bbpress.rb

Félicitations ! Votre base de données a été migrée avec succès de bbPress vers Discourse

Prenez maintenant une sauvegarde depuis la page d’administration /admin/backups et importez-la sur votre site Discourse en production.

Après avoir déplacé votre forum bbPress vers Discourse, si vous continuez à utiliser votre site WordPress comme site principal et que vous souhaitez le connecter à Discourse, installez le plugin WordPress officiel de Discourse.

Just wanted to thank you for providing this step-by-step guide. We migrated our site from bbpress to Discourse with minimal headache thanks to you. Since we’re running multisite wordpress there were a few tweaks to make to the importer, but other than that it went very smoothly. Thanks!

If you can share your tweaks then it will be helpful to other multisite owners.

Admittedly I didn’t take very good notes, and have since killed the VM it
was on (sorry!) but the basic gist is that if your bbpress install is not
on the primary site of the Multisite setup you’ll need to a) set the
environmental variable for BBPRESS_PREFIX to include your site’s ID number
(e.g. wp_6_ ) and then edit the migration script to use wp_users rather
than #{BBPRESS_PREFIX} for the Users sql. This is because on Multisite
installations the wp_users table is shared across sites and then each site
has its own tables for posts, postmeta, etc.

thanks for the details

I recently posted on how to import bbpress into discourse

Great job on the tutorial! But it’s confusing to have two different guides on this. Do they serve different purposes? Otherwise we should figure out how to merge them.

That guide is about how to import bbpress inside of a development environment, mine is how to import bbpress using the docker container. It’s just 2 different ways to go. I’d recommend importing via docker container since it doesn’t ask for the additional step of setting up a development environment, which can be cumbersome.

Hello I am stuck trying to import successfully after all users are done importing.

As soon it begins to import anonymous users it cancels with an error of “Invalid Email… and Validation failed: Username can’t be blank (ActiveRecord::RecordInvalid)”.

I added the error below, does anyone encountered this before or have any ideas on what I should do?

Thanks,

importing anonymous users...
Invalid email '' for ''. Using '6be92499a6f885cb271d94bffd5e667b@email.invalid'
Error on record: {:id=>"", :email=>"", :name=>"", :website=>nil}
Traceback (most recent call last):
	23: from script/import_scripts/bbpress.rb:512:in `<main>'
	22: from /home/lutechi/discourse/script/import_scripts/base.rb:49:in `perform'
	21: from script/import_scripts/bbpress.rb:31:in `execute'
	20: from script/import_scripts/bbpress.rb:153:in `import_anonymous_users'
	19: from /home/lutechi/discourse/script/import_scripts/base.rb:249:in `create_users'
	18: from /home/lutechi/discourse/script/import_scripts/base.rb:249:in `each'
	17: from /home/lutechi/discourse/script/import_scripts/base.rb:261:in `block in create_users'
	16: from /home/lutechi/discourse/script/import_scripts/base.rb:337:in `create_user'
	15: from /home/lutechi/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/transactions.rb:212:in `transaction'
	14: from /home/lutechi/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/connection_adapters/abstract/database_statements.rb:267:in `transaction'
	13: from /home/lutechi/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/connection_adapters/abstract/transaction.rb:236:in `within_new_transaction'
	12: from /home/lutechi/.rbenv/versions/2.6.2/lib/ruby/2.6.0/monitor.rb:230:in `mon_synchronize'
	11: from /home/lutechi/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/connection_adapters/abstract/transaction.rb:239:in `block in within_new_transaction'
	10: from /home/lutechi/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/connection_adapters/abstract/database_statements.rb:267:in `block in transaction'
	 9: from /home/lutechi/discourse/script/import_scripts/base.rb:338:in `block in create_user'
	 8: from /home/lutechi/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/suppressor.rb:48:in `save!'
	 7: from /home/lutechi/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/transactions.rb:315:in `save!'
	 6: from /home/lutechi/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/transactions.rb:385:in `with_transaction_returning_status'
	 5: from /home/lutechi/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/transactions.rb:212:in `transaction'
	 4: from /home/lutechi/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/connection_adapters/abstract/database_statements.rb:265:in `transaction'
	 3: from /home/lutechi/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/transactions.rb:387:in `block in with_transaction_returning_status'
	 2: from /home/lutechi/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/transactions.rb:315:in `block in save!'
	 1: from /home/lutechi/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/validations.rb:52:in `save!'
/home/lutechi/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/validations.rb:80:in `raise_validation_error': Validation failed: Username can't be blank (ActiveRecord::RecordInvalid)

Merci pour ce tutoriel utile — cela a fonctionné pour moi, bien que j’aie quelques petits problèmes :

1. Le processus d’installation semblait installer PostgreSQL 11, alors que la version hébergée de Discourse prend en charge PostgreSQL 10, ce qui leur cause quelques soucis !

2. Les utilisateurs importés ne semblent pas pouvoir se connecter à Discourse avec leurs identifiants WordPress — j’ai essayé avec mon propre compte, à la fois avec le nom d’utilisateur et l’adresse e-mail, mais aucun des deux ne fonctionne. Je peux me connecter à WordPress sans problème et le compte utilisateur est présent dans Discourse, avec les fils de discussion associés. Quelque chose a-t-il changé concernant les mots de passe ou l’authentification ?

Utilisez-vous l’authentification unique (SSO) depuis WordPress ?

Cela nécessite le plugin migrate password. L’avez-vous installé ?

Bonjour Michael,

Non, c’est la première référence que j’ai trouvée concernant ce plugin, alors merci de me l’avoir signalée — j’ai peut-être manqué une étape quelque part ! Merci de l’avoir partagée, je vais y jeter un coup d’œil plus attentif demain, quand mes yeux seront moins fatigués !

Ruth

Bonjour

Les images téléversées par les utilisateurs peuvent-elles également être migrées ?
Le plugin pour les téléversements des utilisateurs était GD bbPress Attachments.

Salutations

Le script semble importer des pièces jointes.

Vous devez définir une variable d’environnement BB_PRESS_ATTACHMENTS_DIR avec le chemin d’accès aux pièces jointes.

Les téléchargements du plugin bbPress semblent être stockés dans le dossier /uploads de l’installation WordPress. C’était géré par GD bbPress Attachments. Je ne suis pas sûr du type de chemin que je devrais indiquer dans la variable BB_PRESS_ATTACHMENTS_DIR. Pourriez-vous m’aider un peu ? Dois-je mettre le chemin d’accès URL complet vers les fichiers téléchargés, par exemple http://www.example.com/httpdocs/wp-content/uploads/2018/02/picture.png, ou autre chose ?

J’ai remarqué que le script d’importation ne s’est pas terminé avec succès, car l’étape import_private_messages a échoué. Les messages privés n’étaient pas activés sur le forum. J’ai supprimé cette étape du script, mais il échoue maintenant avec le message : table wp_bb_attachments doesn't exist, ce qui est exact. Je ne trouve cependant aucune table pour les pièces jointes dans la base de données. Comment ces pièces jointes ont-elles pu fonctionner au départ ?

Les pièces jointes doivent se trouver dans un répertoire sur le serveur où vous exécutez l’importation.

Si vous ne voyez pas la table de pièces jointes que le script recherche, il se peut que vous ayez utilisé une méthode différente de gestion des pièces jointes de celle attendue par le script. Je suppose qu’elles se trouvent soit dans une autre table que vous n’avez pas encore trouvée, soit que le nom de fichier relatif est intégré dans les messages eux-mêmes.

Il semble que vous ayez besoin d’une autre fonction pour les importer. Si vous avez un budget, je peux vous aider. Redirecting… contient des informations sur les importations. Vous n’avez pas l’air d’avoir besoin du service complet, donc votre coût sera inférieur à ce qui y est suggéré.

Puisque Discourse s’exécute toujours dans un conteneur Docker, ce répertoire doit-il être lié au conteneur d’importation ?

Correct. Si vous lancez l’importation depuis un conteneur, vous devez placer ces images à un endroit accessible depuis le conteneur et utiliser ce chemin.

Une dernière question. Puisque vous avez mentionné votre service d’importation, j’ai consulté le site et creusé davantage dans ma base de données pour trouver où sont stockées les pièces jointes. Une phrase sur votre page m’a légèrement inquiété :

Par exemple, certains forums peuvent joindre des fichiers à un message sans les mentionner dans le corps du message. Le script d’importation identifie les pièces jointes en remplaçant les références qui y sont faites dans le corps du message ; dans ce cas, les pièces jointes non liées sont omises.

J’ai constaté que mes pièces jointes étaient stockées dans la table wp_postsmeta sous la forme _wp_attached_file. Cependant, le message lui-même, qui contient cette pièce jointe liée, ne fait aucune mention de celle-ci dans son corps. Il semble que le seul lien ici soit entre post_id et meta_id. Cela signifie-t-il qu’il s’agit d’une « pièce jointe non liée » et qu’elle sera omise ?