実際には3.3なので、phpBBのそのバージョンと互換性を持たせるためのPRを待つ間、または以前提案されたバージョンチェックの編集を使って現在のスクリプトで試す間、準備作業を行っています。
xml_to_markdown.rbを扱う必要がありそうですね。
実際には3.3なので、phpBBのそのバージョンと互換性を持たせるためのPRを待つ間、または以前提案されたバージョンチェックの編集を使って現在のスクリプトで試す間、準備作業を行っています。
xml_to_markdown.rbを扱う必要がありそうですね。
phpBB 3.3.x フォーラムでのテストインポートの試みは完全に失敗しましたが、その詳細については後述します。
試行錯誤の過程で多くのことを学び、それが他のインポートや、phpBB 3.3 用のインポートスクリプトが更新された際に役立つかもしれないと思い、共有することにしました。
バージョンチェックを通過するために /script/import_scripts/phpbb3/database/database.rb を編集する必要がある場合、またはカスタムBBCodeを追加するために /script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb を編集する必要がある場合は、次のコマンドでインポートを開始した後に実行するタイミングです。
/var/discourse/launcher enter import
その時点で、nano を使用してファイルを編集できます。
phpBB 3.3 フォーラムでのインポートの試みが失敗したため、カスタムBBCodeの変更が効果的であったかどうかは確信が持てませんが、phpBB 3.2 以降では、上記のように /script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb ファイルを編集し、次のような形式で定義を追加するだけでよいようです。
def visit_<大文字小文字を区別するカスタムBBCodeをここに> (xml_node, md_node)
# 処理コードをここに記述
end
繰り返しますが、まだテストできていませんが、phpBB で非常に一般的なカスタムBBCodeで、xml_to_markdown.rb の私のバージョンには存在しないものがあります。それは次のとおりです。
[YouTube]{Identifier}[/YouTube]
ここで、{Identifier} は YouTube URL のクエリ文字列の「v」の値です。
そのため、Ruby初心者としての私の xml_to_markdown.rb へのコード追加の試みは次のとおりです。
def visit_YouTube (xml_node, md_node)
content = xml_node.content
url = "https://www.youtube.com/watch?v=" + content
md_node.text = "#{url}"
md_node.prefix_linebreaks = md_node.postfix_linebreaks = 2
md_node.prefix_linebreak_type = LINEBREAK_HTML
end
最後に、インポートスクリプトを実行したところ、データベースロードのステップまでしか到達せず、次のエラーが発生しました。
ERROR 1071 (42000) at line 1233035: Specified key was too long; max key length is 1000 bytes
これが DB エンジン (元は InnoDB を使用) の問題なのかどうかはわかりませんが、phpBB 3.3 版のスクリプトで対処されるだろうと推測しています。
わかりました、これを放っておけませんでした。
エラーはインポートスクリプトで処理できる可能性もありますが、phpBB3のデータベース構造と、私のデータベース照合順序がUTF8であるという事実の問題のように思えます。インポートスクリプトを実行したときにこのエラーが発生しました。
ERROR 1071 (42000) at line 1233035: Specified key was too long; max key length is 1000 bytes
phpbb_mysql.sqlファイルの1233035行目(データのダンプのローカルコピーを使用しています)を確認したところ、次のことがわかりました。
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`),
ADD KEY `is_dynamic` (`is_dynamic`);
phpbb_configテーブルのconfig_name列を見ると、VARCHAR(255)に設定されていることがわかりました。
Stackoverflowのこの投稿のおかげで、「プレフィックスインデックス」を使用してキーの長さを短縮できることがわかりました。テストしたところ、うまくいきました。
私のphpBB 3.3.8データベースでは、実際には4つのテーブルが影響を受けました。
他に試したい方がいれば、phpbb_configテーブルの手順を以下に示します。他のテーブルのクエリは最後に含めます。
このクエリを使用して、プレフィックスインデックスの最短値を計算します。
SELECT
ROUND(SUM(LENGTH(`config_name`)<10)*100/COUNT(`config_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`config_name`)<20)*100/COUNT(`config_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`config_name`)<50)*100/COUNT(`config_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`config_name`)<100)*100/COUNT(`config_name`),2) AS pct_length_100
FROM `phpbb_config`;
私の場合は、100%の行が50文字未満であることが示されたため、データダンプファイルを編集しました。
nano /var/discourse/shared/standalone/import/data/phpbb_mysql.sql
そして、次の文字列を検索 Ctrl+W して使用しました。
ALTER TABLE `phpbb_config`
そして、これを変更しました。
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`),
ADD KEY `is_dynamic` (`is_dynamic`);
これを次のように変更しました。
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`(50)),
ADD KEY `is_dynamic` (`is_dynamic`);
そこにある (50) はプレフィックスインデックスの長さです。
私の場合は、最適なプレフィックスキー長を取得するために、他の3つのテーブルで同じプロセスを繰り返す必要がありました。
SELECT
ROUND(SUM(LENGTH(`config_name`)<10)*100/COUNT(`config_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`config_name`)<20)*100/COUNT(`config_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`config_name`)<50)*100/COUNT(`config_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`config_name`)<100)*100/COUNT(`config_name`),2) AS pct_length_100
FROM `phpbb_config_text`;
SELECT
ROUND(SUM(LENGTH(`migration_name`)<10)*100/COUNT(`migration_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`migration_name`)<20)*100/COUNT(`migration_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`migration_name`)<50)*100/COUNT(`migration_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`migration_name`)<100)*100/COUNT(`migration_name`),2) AS pct_length_100
FROM `phpbb_migrations`;
SELECT
ROUND(SUM(LENGTH(`provider`)<10)*100/COUNT(`provider`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`provider`)<20)*100/COUNT(`provider`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`provider`)<50)*100/COUNT(`provider`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`provider`)<100)*100/COUNT(`provider`),2) AS pct_length_100
FROM `phpbb_oauth_accounts`;
他のテーブルの検索文字列を以下に示します。
ALTER TABLE `phpbb_config_text`
ALTER TABLE `phpbb_migrations`
ALTER TABLE `phpbb_oauth_accounts`
これで万事解決したとは言えませんが、上記の対処法で最初のデータベースエラーは解消され、インポートが実行されています。
#import_phpbb3.sh
The phpBB3 import is starting...
Loading existing groups...
Loading existing users...
Loading existing categories...
Loading existing posts...
Loading existing topics...
importing from phpBB 3.3.8
creating users
722 / 5014 ( 14.4%) [58 items/min]
更新:
インポートスクリプトは9時間28分で完了しました。Screenに感謝します。このスクリプトは素晴らしいです!
後処理が現在進行中です。
インポートスクリプトの出力のログはどこかにありますか、それともファイルにリダイレクトすべきでしたか?
WSL上のDockerコンテナでdiscourse_devを実行する場合、phpbb3インポーターのどちらの手順を使用すべきでしょうか?
手順1「Dockerコンテナを使用したインポート」と手順2「開発環境を使用したインポート」の両方を試しましたが、どちらもうまくいきませんでした。手順1ではスクリプトは完了まで実行できましたが、多くのクエリが成功したように見えたにもかかわらず、フォーラムデータベースにデータが実際にはインポートされませんでした。インポートがdiscourse_devコンテナとは別の独自のコンテナで実行されているため、別のデータベースが投入されている可能性はありますか?
手順2の場合、ビルドを実行することは単純に不可能であり、「tiny_tds (2.1.5) のインストール中にエラーが発生し、Bundler は続行できません。」というエラーで失敗します。
WSLで「標準インストール」(Dockerなし、開発環境なし)を試してから、Dockerベースのインポートを実行すべきでしょうか?
それがおすすめです。開発環境での移行はめったに行いません。
また、mssqlではなくmysql/mariadbを使用しない限り、tiny_tdsは不要です。
ジェイさん、どうもありがとうございます。あなたのチュートリアルは的確で、本当に助かっています。
VPSにDiscourseを標準のDockerインストールプロセスを使用して正常にインストールしました。次に、これらの手順に従ってインポートプロセスを実行したところ、スクリプトは問題なく完了しました。コンテナを終了し、stop importを発行したところ、次のメッセージが表示されました。
‘’/var/lib/docker が配置されているディスクに 5GB 未満の空き容量があります。続行するには、より多くの空き容量が必要です。
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 24G 20G 2.7G 89% /
システム内のDockerイメージとコンテナをクリーンアップしてスペースを回復しようとしますか? (y/N)‘’
スペースの回復では、追加の空き容量は得られませんでした。どうすればよいですか?アップロードしたすべてのイメージファイルを /data から安全に削除できますか?それらがまだ必要かどうかはわかりません。
よろしくお願いします。
インポートが完了したように見え、インポートされるはずだった画像について話している場合、問題ないはずですが、バックアップを作成するには十分なスペースがない可能性が高いです。ドロップレットをアップグレードしてスペースを増やすことをお勧めします。1日あたりの料金はそれほど大きな問題にはならないはずです。
ジェイ、アドバイスありがとうございます。
これらの詳細が他の人の役に立つ場合に備えて、画像ファイルのみを削除したところ、約 3.4 GB が解放され、合計 6.1 GB が利用可能になり、Sidekiq はその後、後処理を正常に完了しました。ディスク容量はその後、さらに 20 GB 増加しました。
参考までに、これは phpBB バージョン 3.3.0 の掲示板のインポートで、73,000 件を超える投稿、8,000 件を超えるトピック、1,300 人を超えるユーザーが含まれていました。
現時点で発見した唯一の問題は、一部のユーザー名が奇妙であることですが、これは上記で議論されており、致命的ではありません。
このインポートとソースの phpBB フォーラムの閉鎖の間には間隔があります。インポート Docker コンテナをそのままにしておき、このインポート以降に行われた投稿を移行するために増分バックアップに使用できますか?
phpBB 3.3.xの移行を行ったとき、最終インポートのために、phpBBサイトを「メンテナンスモード」にし、rsyncを使用して添付ファイル、アバター、スマイリーを更新し、新しいデータダンプをインポートしてから、インポートを再構築してインポートスクリプトの最終実行を行いましたが、それより前にインポートを終了していました。
@DonH phpBBのパスワードをインポートして、Migrate Passwordsプラグインで機能させましたか?
phpBBのパスワードをインポートしなかったのには、いくつかの理由があります。プラグインとの潜在的な競合を避けたかったのと、ユーザーにパスワードのアップグレードを強制したかったからです。この移行は、そのための良い方法(そして良い口実)になると考えました。phpBBのウェブホスティングでは、セキュリティはホスティング会社によって処理されていましたが、新しいVPSではそのような贅沢はありません。
はっきりさせるために、データベース全体を最後に再インポートし、増分アップデートは行わなかったということですか?
私の理解と経験では、phpBBフォーラムのデータダンプ(たとえばphpMyAdminから)を取得し、ファイルを/var/discourse/shared/standalone/import/dataにアップロードし、インポートを再構築してからインポートコマンドを再実行すると、移行スクリプトは既にインポートされたユーザーアカウントや投稿などには触れず、以前にインポートされなかったデータベースエントリのみを処理します。
本質的には増分更新を行っていますが、既存のエントリには触れないため、ユーザーが既にインポートされた投稿を編集したり、メールアドレスを変更したりした場合など、一部のデータが失われる可能性があります。
プラグイン設定の migratepassword_allow_insecure_passwords をチェックしない場合、migratepassword プラグインは、Discourse によって安全でないと見なされたインポート済みパスワードを許可せず、最小長や一意の文字などのすべての複雑さ設定を尊重します。
どのようなプラグインの競合について言及されているのか分かりません。
@RGJ migratepassword プラグインは phpBB 3.3 で動作しますか?
現在、phpBB 3.3.8 フォーラムでインポートを実行しており、パスワードをインポートして試しています。
myBBから移行するにはどうすればよいですか?
myBBとタグ #migration::tag を検索すると、howto が見つかるかもしれません。
Ok、情報ありがとうございます!
リチャード、明確にしてくれてありがとう。特定の紛争を指していたわけではなく、見慣れない地域で予期せぬことが起こる可能性について言及しただけです。プラグインを追加する前に意図的にインポートを実行しました。しかし、主に、メンバーにパスワードをアップグレードさせることを強制したいのです。
この移行は本当に問題なく完了しました。ゲルハルトと関係者全員の、落ち着いたスクリプトに称賛を送ります。新しいメッセージボードをカスタマイズするのが楽しみです。
はい、動作します。最近プラグインに Argon2 サポートを追加しました。
リチャードは彼のホスティングでプラグインをサポートしています。それが問題を引き起こしたという話は聞いたことがありません。多くのインポーターがパスワードをインポートし、それが機能します。私が書いた他のランダムなフォーラムのインポートスクリプトでも機能しました。