返信ありがとうございます。
「公式」の方法はMySQLデータベースにアクセスし、ENV変数でmybb.rbスクリプトを使用することに依存していることは理解しています。そして、はい、私はそれを試しました。また、インポートガイドで推奨されているように、完全なローカルDiscourse開発環境をセットアップしようとしました。そして、インポート後にデータを本番環境に移行する予定でした。しかし、現実には、「Discourseへの移行」カテゴリで見つけたチュートリアルや例のほとんどは、古くなっているか、MyBBインポーターでエラーが発生している人々で溢れています。
スクリプト自体は壊れやすいです。古くなっており、わずかなスキーマの違いやエッジケースで壊れます。ほとんどのガイドは、Ruby、Rails、およびDiscourseコードベースの内部構造に精通していることを前提としていますが、多くのフォーラム管理者にはそれができません。そして、CSVにエクスポートすることで物事を単純化しようとしたときでさえ、提供されたツールが機能しなかったため、データを手動で準備しようとすることの方が多かったです。
*「それらはすべてほぼ同じように機能します」*とおっしゃったとき、確かに、それが問題です。それらの多くは、大幅なパッチ適用、デバッグ、および推測なしでは2025年にはうまく機能しません。人々が苦労しているのは、ドキュメントを読んでいないからではなく、インポートのエコシステムが開発者中心の考え方に固執しているからです。
この時点で、MyBB SQLを、管理パネルからアップロードして復元できる、動作するDiscourseの.tar.gzバックアップに変換することにしました。インポートスクリプトなし、Rubyエラーなし、クリーンで直接的な方法で機能します。
そして正直なところ、人々がMyBB SQLファイルをドラッグアンドドロップしてDiscourse対応のバックアップにエクスポートできるPythonツールを作成するつもりです。このプロセス全体が、最新のユーザーフレンドリーなインポートパスがいかに必要とされているかを示してくれました。コミュニティを移行するためだけに、ユーザーがこれほど多くの苦痛を経験する必要はありません。
それでも助けてくれてありがとう。あなたはただ明確にしようとしているだけで、私は誰かを具体的に非難しているわけではありません。しかし、インポート体験全体は間違いなく見直しが必要です。