試しましたが、以下の問題が発生しています。すべての投稿はインポートされましたが、トピックのタイトルが表示されず、外部画像が表示されません。 現在のSMF2フォーラムは次のとおりです: https://forum.mundofotografico.com.br Discourseに移行しようとしているのはこちらです: https://discourse.fotografos.online - すべてのトピックと適切な説明が移行されておらず、画像が読み込まれていません…助けてください！ @marcozambi @miligraf @FireAllianceNX @pfaffman
SMF移行プロセスを開始したばかりで、現在、テストインスタンスに1時間あたり約1000件のペースで投稿をインポートしています。今のところすべて順調ですが、MySQLのパフォーマンススクリプトで、なぜかMySQLが「ALTER USER」コマンドを認識しませんでした。「CREATE USER」をマニュアルで実行したところ、その後は問題なく動作しました。
削除されたユーザーに関するコメントを読みましたが、削除されたユーザーすべてをカバーするために新しいユーザー/偽のメールアドレスを簡単に作成することはできません（私のフォーラムは20年以上稼働しており、実際のユーザーよりも削除されたユーザーの方が多い可能性があります）。削除されたユーザーは4000〜5000人いると推測しています。すべてが投稿したわけではありませんが、多くが投稿しているため、数百人の「不明な」ユーザーがいる可能性があります。
投稿は「system」に属するものとしてインポートされていますが、これは実際には理想的ではありません。以下の方法が機能するかどうか疑問に思いました。
- インポートする前に、ダミーユーザー（例：「Deleted User」）を作成します。
- 「Deleted User」のユーザー番号を調べます。
- smf2.rb の「user_id: user_id_from_imported_user_id(message[:id_member]) || -1,」という行を修正し、「-1」を「Deleted User」のユーザー番号に置き換えます（システムユーザーは-1だと思いますか？）。
これで機能しますか？また、smf2.rb で同様の変更が必要な他の場所はありますか？
こんにちは、「削除された」とは、SMFデータベースから実際に削除されたという意味ですか、それともユーザー名とメールアドレスがデータベースに残っていて、一時停止としてマークされているという意味ですか？それらの「削除された」ユーザーの投稿は、SMFでは現在どのように表示されていますか？
私はDrupalからDiscourseへの大規模な移行の途中にあり、これもまた、多数の一時停止中のユーザーがいる長年のフォーラムからのものです。それらの停止中のユーザー名とその関連メールアドレスをDiscourseで維持することを強く望んでいたため、DiscourseのDrupalインポーター スクリプトにその機能を追加する必要がありました。基本的に、スクリプトはすべてのユーザーを通常の有効なユーザーとしてインポートし、公開可能な投稿があれば、元のフォーラムと同様にインポートされます。その後、プロセスの最後に、別のインポーター スクリプトから取得した関数を追加し、Drupalデータベースを調べ、ユーザーが一時停止としてマークされていた場合は、Discourseアカウントも一時停止するようにしました。そのコードは、ここの私の投稿履歴で確認できます。
「いいね！」 1
こんにちは。ユーザーは実際に削除されており、smf_member テーブルにレコードがなくなっています。SMF にはユーザーを一時停止する機能はありません。ユーザーを禁止することはできますが、ユーザーが死亡したり、趣味やフォーラムへの関心を失ったりした場合のアカウントには適切ではないようです。データ保護の観点からも、あまり適切ではありません。
SMF の投稿には、レコードごとに 2 つのフィールドが保存されています。ユーザーメンバー番号（削除されたユーザーの場合はゼロに設定されます）と、投稿者名（投稿者のユーザー名が含まれます）です。そのため、どのユーザーがメッセージを投稿したかを確認できますが、ユーザーの詳細（メールアドレス、氏名など）はもう利用できません。投稿は表示される際に「ゲスト」マーカーが付いています。
メンバー ID がゼロのメッセージを投稿したすべてのユーザーに対して新しいアカウントを作成し、ダミーのメールアドレスを割り当ててから、ユーザーを一時停止としてマークするという方法が考えられます。一意で識別可能なものを使用すれば、ダミーのメールアカウントの形式に基づいてアカウントを一時停止としてマークできます。しかし、場合によっては少し奇妙に感じられます… 10〜15年前に亡くなったことがわかっている人たちのためにアカウントを作成するのですから！
しかし、これについては考える時間があります…移行は部分的に成功しましたが、添付ファイルが添付されなかった理由、フォーラム内のリンクが変更されなかった理由、移行されたユーザーのパスワードが機能しない理由を突き止める必要があります。他にも問題があるかもしれませんが、まずはそれらの問題を修正し、他に何が起こるかを確認します。
Postgresのことですか？何について話しているのかよくわかりません。
私がやるなら、ユーザーIDが0の場合は、ユーザー名IDを使用します。次に、find_username_by_import_idがユーザーを見つけられない場合は、ユーザーを作成し、メールアドレスをfake_email（base.rbの関数で、偽のメールアドレスを生成します）に、ユーザー名を指定したユーザー名に設定します。その後、野心的であれば、スクリプトの最後に@email.invalidをメールアドレスに含むすべてのユーザーを一時停止できます。それらはアクティブではないので、一時停止しなくてもあまり問題ないと思います。
別の方法としては、削除されたユーザーのリストを生成し、投稿を開始する前にそれらを作成するクエリを実行することですが、それはより困難なようです。
「deleted user」というユーザーを作成し、それらの投稿すべてを「system」ではなくそのユーザーに所有させたい場合は、それを行うことができます。-1を「deleted user」のユーザー番号に置き換えるだけです。通常のユーザーとして作成することも、何か派手なことをしてユーザーIDを-2などにすることもできます。
一部のシステムでは、添付ファイルが投稿本文に含まれている場合と、添付ファイルレコードがデータベースにある場合があります。
インポートを実行した後、Migrated password hashes supportプラグインをインストールしましたか（少なくともいくつかの状況ではインポートの実行に干渉する可能性があります）。SMF2は、smf doesと同じ方法でパスワードをハッシュしますか？
すみません、スクリプトの名前を間違えました。最初の投稿で言及されているMySQLスクリプトです。
– file: ~/smf2/script_for_mysql_tuning.sql
ALTER USER ‘user’@‘%’ IDENTIFIED WITH mysql_native_password BY ‘pass’;
ユーザー、特にfake_emailに関する提案ありがとうございます。私の最初のタスクは、インポートスクリプトを変更できるようになるために、十分なRubyを学ぶことです！
SMF2の添付ファイルはデータベース内のレコードです。もう少し深く掘り下げてみると、いくつかインポートされたようですが、数万件のうち数百件にすぎません。理由を突き止めるために、さらに調査を続けます。
ああ、おそらくそれが見落としだったのでしょう！SMF2はSMF1と同じハッシュ（塩漬けMD5だったと思います）を使用していると確信しているので、プラグインが問題を解決してくれることを願っています。ユーザーのログインについては、それほど心配する前に、さらにインポートを実行する必要があります。
もう一つ質問があります。インポートをやり直せるようにシステムをリセットする方法はありますか？開始前にバックアップを取るべきでしたが、忘れてしまいました 
ああ。MySQLの設定だけのことですね。なるほど。
他の言語を知っていれば、なんとかできるでしょう。
私はRubyを学ぶ前に、いくつかのインポーターを書きました。
ここに、Discourseデータベースを削除して新しく作成する一つの方法があります。
sv stop unicorn;DISABLE_DATABASE_ENVIRONMENT_CHECK=1 IMPORT=1 rake db:drop db:create db:migrate; sv start unicorn
バックアップをすることを覚えていれば、もう少し速くなるかもしれません。
もう一つのトリックは、ユーザーを把握したら、ユーザーのインポート後にスクリプトを停止し、その時点でバックアップを作成することです。これにより、ユーザーを再度インポートすることなく、投稿のインポートをデバッグできます。
いくつか知っています。最初のプログラムは1976年にIntel 4004でバイナリマシンコードで書きました。smf2.rbを理解し始めているところですが、私にとって新しいコード構造を理解するためにDuckDuckGoを使っています。
データベースのドロップ/作成メソッドに感謝します。最初からやり直して、私のデータ用のインポーターに段階的な変更を加えてみようと思います。
「いいね！」 1
インポータを改造して、削除されたユーザーのダミーアカウントを偽のメールアドレスで作成し、ダミーアカウントが正しい投稿を所有するようにしました。これは良いスタートです。
次に添付ファイルを理解しようとしていますが、これまでにインポートした投稿には添付ファイルが見当たらないため（添付ファイルがあるはずです）。
Discourseのウェブページから通常のメッセージを作成すると、投稿テーブルにレコード（id=4346）、アップロードテーブルに2つのレコード（ids=403および404）、アップロード参照テーブルに4つのレコード（403/Draft/4、403/Post/4346、404/Draft/4、404/Post/4346）が作成されます。また、投稿4346のimage_upload_idフィールドに403があり、posts/cookedフィールドに2つのアップロードを参照するHTMLがあります。
インポートされた投稿では、インポートされたSMFメッセージごとに投稿テーブルのレコードが作成され、インポートされたSMFメッセージに関連付けられた各添付ファイルに対してアップロードテーブルのレコードが作成されます。アップロードテーブルのレコードは、正しい画像を含むディスクファイルを指しているため、その部分は正常に機能しています。しかし、アップロードされた画像に対するアップロード参照レコードや、投稿テーブルのimage_upload_idフィールドにあるアップロードIDは作成されません。
アップロード参照レコードを作成し、posts-image_upload_idおよびcookedフィールドをポップレートする必要があると思いますが、インポータが使用している（または使用しようとしている）アップロードと投稿を関連付ける他の方法がないか確認したいと思いました。
ホスト/アップロードへの参照を raw に追加する必要があるようです。リンクを生成する関数がいくつかあります。名前は思い出せませんが、アップロードモデルにあると思います。モデルが何かわからない場合は、他のインポートスクリプトで見つける方が簡単なかもしれません。
Discourse ベータ版の最新アップデート後、インポートコンテナをビルドできなくなりました。以下のようなエラーが発生します。
> 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.
yarn キーの有効期限切れに関する投稿は確認済みで、修正しました。これにより libmariadb-dev パッケージのインストールが停止していましたが、手動でパッケージをインストールしたところ正常に動作しました。MariaDB パッケージを手動でインストールした後でも、mysql インポートテンプレートを有効にした状態での再ビルドは機能しません。
新しいサーバーを構築し、以前のサーバー/インストールからの潜在的な問題を回避するために、Discourse をクリーンインストールしました。しかし、新しいサーバーでも古いサーバーと同じエラーが発生します。
次に何を試すべきか分かりません。何か提案があれば歓迎します！
Apt-get update fails inside container yarn repo not signed - #5 by pfaffman を参照してください。mysql テンプレートを編集する必要があります。
「いいね！」 1
正しい方向を示していただきありがとうございます。今、何が間違っていたのかわかりました！
「いいね！」 1
SMF 2 (具体的には v2.0.15) フォーラムのテスト移行を開始したところ、最初に発生した問題の 1 つは、カテゴリ名にアンパサンド (&) が含まれている場合の問題です。
同様のアンパサンドを含むスレッドタイトルは問題ないようです。
これまでのところ、アンパサンドのみが問題のある文字であり、例えばドイツ語のウムラウトは問題ないようです。
おそらく、このスレッドで報告されている問題 (削除されたユーザー、添付ファイル、フォーラム内のリンク) も影響を受けていると思われますが、インポートはまだ実行中ですので、完了したら更新します。
この点に関して、インポート速度は本当に遅いものなのでしょうか。現在、AMD Ryzen 5 3600 マシン、64GB RAM (Hetzner、Ubuntu 22.04) で 1750 件/分 (当初は 2000 件/分に近かった) でインポートしており、移行全体で約 3 日かかります。
それはかなり良い速度ですね。
報告された問題はまだ残っていると思いますが、フォーラムに特有のものが驚くほどたくさんあります。修正したいものがあり、予算があれば喜んでお手伝いします。
「いいね！」 1
ありがとうございます！状況がより具体的になったら、改めてご連絡します。
現在、私たちは（テーブルトークRPGや関連ホビーを中心とした小規模な非営利団体）評価段階にあり、新しいソフトウェアが必要であるという共通認識があり、これまでのところDiscourseが最有力候補です。しかし、すべてのToDo（移行、新しいテーマ、必要であれば新しいプラグイン/テーマコンポーネント）を収集し、すべてを予算に収めることができるかどうかを確認する必要があります。
「いいね！」 1
この手順には特別な理由がありますか？
OPを注意深く再読した限りでは、その smf2.rb ファイルは変更/パッチされていませんか？
そして、smf2.rb がホストの（例えば）/var/discourse/smf2 にあり、ステップ2でボリュームマウントを適切に設定した場合、それはゲスト内の /shared/smf2 にマウントされます。
なぜそれを別のステップとしてコピーする必要があるのか理解できません。しかし、これを理解することが、95%の添付ファイルがスクリプトによって正しく見つけられない理由を解明する鍵となるかもしれません…
「いいね！」 1
コピーする必要がないというあなたの考えは正しいようです。おそらく、著者がそれを変更し、その変更がその後コアに組み込まれたのでしょう。
0%ではなく5%の添付ファイルが見つかっているということは、スクリプトに何か問題があるようです。
システムによっては、ファイルを添付する方法が2つあります。1つはファイル内で言及する方法（投稿の生のテキストに含まれ、そのように処理される）、もう1つはメタデータ/テーブルで投稿に添付する方法です。おそらく、データベースの95%は一方の方法で、スクリプトはもう一方の方法を使用しているのでしょう。
しかし、両方の方法を試しているようにも見えますか？添付ファイルがある投稿を見つけ、データベースとファイルシステムでどのように保存されているかを確認し、コードを見てなぜ取得できないのかを調べる必要があります。
「いいね！」 1
@pfaffman、ありがとうございます。安心しました！その可能性が高いと思っていましたが、このインポートに非常に苦労しているので、あらゆるレベルで自分の知識とスキルに疑問を持っていました！
アドバイスありがとうございます、すべて感謝いたします @pfaffman - これは昨年取り組んでいたのと同じフォーラムの、大幅に遅れていた再試行です。ボランティアの仕事ですが、もし時間があればまたあなたを巻き込むかもしれません。
これは非常に古いSMF2フォーラムで、添付ファイルは次の2つの形式で保存されています。
id_ファイル名_NO_CLEAR-case_rules_jpg_32文字のMD5ハッシュと思われるものid_40文字のSHA1ハッシュと思われるもの
失敗のパターンをまだ解明しようとしています。
私の推測では（コードを見ずに！）それらのうちの1つがスクリプトが行うことで、もう1つはそうではない（おそらく一方は古い方法で、新しい投稿はその別の方法を使用していますが、他の方法を使用しているものを元に戻して修正しませんでした）。
convert_message_bodyと添付ファイルテーブルのフィールドを確認してください。何らかの理由でMD5からSHA1に切り替えたのかもしれません。
私が言ったように、これらの一方のバージョンには、テーブルにリンクされているのではなく、アップロードへの参照が含まれている可能性があるため、gsubを使用してそのパターンを検索し、一致した場合はキーを取得してテーブルで検索し、そのファイルでcreate_uploadを実行します。
これで十分だと思いますが、ここで提供できる以上の助けが必要な場合は、私に連絡してください。