2 ヵ月間、当グループは Discourse を一時的なドメインで運用し、実際のドメイン名に合意しました。昨日、古いドメインから新しいドメインへすべてのコンテンツを移行しようと試みました。テキストコンテンツ、ユーザーアカウント、スレッド間のリンクはすべて正しく移行されました。しかし、現在は以下の問題が発生しています：
過去の画像埋め込みがすべて失われているようです。
新しい画像をアップロードできません。
私の手順は以下の通りでした：
新しい DigitalOcean ドロップレット上に新しい Discourse アプリを生成しました。
新しいドメイン名をその新しいドロップレットに接続しました。
両方の Discourse アプリとすべてのプラグインが、利用可能な最新バージョンに更新されていることを確認しました。
新しいコンテンツの追加を防ぐため、古い Discourse を読み取り専用モードに設定しました。
古い Discourse のバックアップを実行しました。
バックアップを新しい Discourse にアップロードしました。
Discourse のメールアドレスを、古いドメインのメールから新しいドメインのメールに更新しました。
通知のテストを実行し、新しい Discourse で正常に動作することを確認しました。
古いドメインへの言及を新しいドメインに更新するため、すべての Discourse 設定を確認しました。
古いサブドメインを適切なドメインにリダイレクトするように変更し、一時的にそこに新しい Discourse への注記とリンクを追加しました。
上記の通り、ほとんどのコンテンツは問題なく移行されたように見えました。しかし、1 日後、古い画像埋め込みが失われ、新しい画像をアップロードできないことに気づきました。表示されているのは「alt」テキストのみです。以下に例のスクリーンショットを示します。
Google 検索では、これに関する長いスレッドがいくつか見つかりましたが、ドメイン名の変更と再アップロードの不可能性を同時に扱ったものは見当たりませんでした。
今すぐこれを解決しようと試みた手順は以下の通りです：
機械に SSH 接続しました。
Discourse ディレクトリに移動し、アプリに入りました。
rake posts:missing_uploads を実行しました。結果は以下の通りです：
Looking for missing uploads on: default
0 post uploads are missing.
rake uploads:missing を実行しました。長いリストが出力されました：
/var/www/discourse/public/uploads/default/original/1X/bbc547e72f080561282be277749165709cbb0983.ico
/var/www/discourse/public/uploads/default/original/1X/0a421ccd1a08047895e2355f44c332f8b069107d.jpeg
/var/www/discourse/public/uploads/default/original/1X/034e0353b7558a26252c82982de53002fda0a33f.jpeg
[…]
/var/www/discourse/public/uploads/default/original/1X/f7a6164ffa55af4ee2706d2386227183ef6c2d61.png
96 of 281 uploads are missing
/var/www/discourse/public/uploads/default/optimized/1X/997bc5536763d84a8d035ff7becd98277a158680_2_45x45.png
[…]
/var/www/discourse/public/uploads/default/optimized/1X/8944afba36549c9050ef074b391625ef93d4d0e3_2_1035x582.jpeg
/var/www/discourse/public/uploads/default/optimized/1X/8944afba36549c9050ef074b391625ef93d4d0e3_2_10x10.png
247 of 761 optimized_images are missing
rake uploads:recover_from_tombstone を実行しましたが、何も出力されませんでした。
これらの Rake コマンドが何をしているのか、私にはわかりません。
また、containers/app.yml ファイル内を確認すると、DISCOURSE_HOSTNAME が正しい（新しい）サブドメインとドメインに設定されていることがわかります。
./launcher rebuild app を実行しても、何も変化しません。
どなたかお手伝いいただけますでしょうか？よろしくお願いいたします。
再ビルドを試しましたか？
cd /var/discourse
./launcher enter app
rake posts:rebake
If the URL to your site changed, yes, it’s a good idea to rebake.
omarfilip:
再ビルドを試しましたか？
ご提案ありがとうございます。さっき指示されたコマンドを入力しましたが、変化は見られません。古い画像は依然として表示されず、新しい画像のアップロードも失敗したままです。なお、アップロード完了時にウェブブラウザのコンソールで「GET 404」エラーが発生しています。
更新：
どのコマンドが状況を改善させたのか正確にはわかりませんが、改善はしたものの完全な解決には至っていません。
新しい TXT、DOCX、XLSX、JPG、PNG ファイルの作成とアップロードは可能です。
ほとんどの（すべてではありませんが）過去のアップロードファイルが、すべての形式で正しく表示・ダウンロードされるようになりました。
問題のあるアップロードファイルは以前は問題なく表示・ダウンロードされていました。しかし、新しいテスト投稿に再アップロードしても表示されません。例を挙げます：
この画像：https://www.frontiersin.org/files/Articles/470644/fphys-10-00944-HTML-r1/image_m/fphys-10-00944-t001.jpg
以下のように、単独の行に URL を入力すると（私の Discourse 上で）正しく表示されます：
しかし、投稿を完了してページをリフレッシュすると、投稿から消えてしまい、空白の行が一つ残っているように見えます。ソースを確認すると、画像要素があり、その SRC 属性には https://discourse.my_domain_name.org/uploads/default/original/1X/61ae2bdeff3dfe334ad6803409560b667d7dc246.jpeg という、私のドメイン上のパスが設定されています。しかし、そのパスを新しいタブで開くと、NGINX の 404 ページが表示されます。
元のソースからダウンロードしてラップトップに保存し、Discourse にアップロードすると（以下でこの Discourse 上でやってみますが）、私の Discourse 上で失敗します。
私の Discourse 上では、このように表示されます：
失敗した画像を Control キーを押しながらクリックして「新しいタブで画像を開く」を選択すると、NGINX の 404 ページが表示されます。
現在の作成ダイアログでは、Discourse が画像の拡張子を JPG から JPEG に変更していますが、それは問題ないと思います。
ダウンロードした画像を Affinity Photo アプリで開き、圧縮なしで新しい JPG としてエクスポートして、再度 Discourse にアップロードすると、Discourse 上で正しく表示されます。
これは、問題がアップロードされたファイルではなく、依然として私の Discourse 側にあることを示唆しています。
Alec
2020 年 10 月 25 日午後 8:28
5
最近の移行中にこの問題に遭遇しました。
技術的な知識がなくても解決できる最も簡単な方法は、FileZillaで元のサイト/ホストにログインし、以下のパスに移動することです。
VAR/Discourse/Uploads
ここには画像を含むサブフォルダがあります。元のホストからそれらをダウンロードし、新しいホストにアップロードするだけです。
より迅速な代替手段として、このバックアップ方法を使用することもできます。手動プロセスですが、これもよく機能しました。
As discussed below , a warning for newbies:
this is an advanced method! there is an automated, web UI way to restore from backups at /admin/backups which is so much easier.
with the method below, no automatic backup is kept of the /var/discourse/containers/app.yml file which contains essential SMTP credentials and SSL customizations. Keep a copy of this offsite whenever you change it.
If you are using digital ocean, keep frequent snapshots of your droplets - preferably before each time you run .…
返信ありがとうございます。私は FileZilla アプリを使ったことがありません。FTP には Transmit アプリを使用しています。しかし、DigitalOcean のドロップレット上の Discourse アプリに FTP で接続する方法がわかりません。
ドロップレットには SSH で接続でき、/var/discourse/ に移動することもできますが、uploads ディレクトリが存在しません。
仮に手動で画像ファイルを古い場所から新しい場所に移動できたとしても、同じ画像の再アップロードが失敗する問題はどのように解決されるのでしょうか？
Alec
2020 年 10 月 25 日午後 10:58
7
Discourse についての非常に初歩的な理解（私は完全に初心者ですが）では、アップロードされた画像はあなたのサイトに保存され、最適化されたファイルサイズのバージョンも同時に保存されます。当初はユーザーに元の画像が表示され、ある時点で（私の経験では 24 時間後でした）フォーラムが最適化された画像に切り替わります。
ストレージ不足が心配だったため、設定を少し実験してみました。
管理ダッシュボードの「Files」セクションで確認できます。画像のサイズや寸法を制御するさまざまな設定があります。これがあなたの「不正な画像」の問題に関連しているかもしれません（私の理解が正しいなら）。例えば、再フォーマットされた画像でも、依然として基準から外れている可能性があります。
私が Digital Ocean から Hetzner にホストを移行した際の問題は、いくつかの画像（およびアバター）が単純に表示されなかったことです（あなたの最初のスクリーンショットと同様）。私の解決策は、それらを FTP で移動させることでした（荒っぽい方法ですが、機能しました）。なぜそうなったのかは 100% 確信はありません。最初は最適化された画像のみを移動しましたが、問題は解決しませんでした。しかし、すべての画像を移動させたところ、問題が解消されました。
フォルダの間違いについてお詫びします。記憶から書いていました。実際のフォルダ構造は以下の通りです：
Digital Ocean では FTP クライアントでログインするのが非常に簡単です。
ホスト：Discourse の IP アドレス
前述の通り、私は専門家ではありません。ここ数ヶ月いじくり回してきただけの者です。
ここではより良いアドバイス（や洞察）を提供できる人々がいます。しかし、他の方法がすべて失敗した場合は、私のアプローチを試してみる価値があるかもしれません。
私の解決策は、FTPでファイルを移動させることでした（荒っぽい方法ですが、機能しました）。なぜそうなるのかは100％確信はありません。最初は最適化された画像だけを移動させたのですが、問題が解決しませんでした。しかし、すべての画像を移動させたところ、私の問題が解消されました。
Discourse 2 台への FTP 接続方法について、より詳しい手順を教えていただきありがとうございます。uploads フォルダは、旧 Discourse で約 125 MB、新 Discourse で 60 MB でした。そこで、旧 Discourse の内容を私のラップトップのデスクトップにコピーし、その後、重複をスキップしながら、フォルダごとに新 Discourse にコピーしました。
驚いたことに、これで問題が解決したようです。すべての画像アップロードが正常に動作するようになりました。Discourse 移行前に作成されたスレッドでも、本日トラブルシューティングのために作成したスレッドでも、どちらも問題ありません。
推測するに、Discourse が何らかの理由で移動中に失われたコンテンツへの既存のポインタを再利用していたのかもしれません。つまり、全く同じ画像ファイルを再アップロードすると、壊れたポインタが再利用され、繰り返し失敗していたのでしょう。しかし、新しいファイルとして保存し直したところ、新しいコピーと新しいポインタが格納されたため、成功したのだと思います。もしかしたら、ですが。
改めて、どうもありがとうございました。
gerhard
2020 年 10 月 26 日午前 12:35
9
デフォルトでは、バックアップには最適化された画像は含まれません。これらは再作成可能であるためです。これらを含めると、帯域幅とディスク容量が無駄になります。
あなたのケースでは、バックアップ作成前に include_thumbnails_in_backups サイト設定を有効にして、それらを含めるようにすれば役立ったでしょう。
別の方法として、リストア後に rake posts:rebake_uncooked_posts を実行しても問題ありません。そうでない場合、最適化された画像はバックグラウンドジョブによって再生成されますが、これには時間がかかります… リストアの最後には、その旨を正確に示すログメッセージが表示されます。
