復元を行ったところ、すべての内部リンクにテストURLドメインが含まれており、すべてのリンクが壊れています。コード/DBに入って一括検索と置換を行わずに、正しいサイトURLが取得されなかった理由がわかりません。他に解決策はありますか？
再復元を考えていますか？
データベースに入り、一括検索/置換を実行する必要があります。
そのためのツールがあります。
RAILS_ENV=production discourse remap //old.domain //new.domain
「いいね！」 4
説明されているように修正できますが、それは起こるべきではありません。
/admin/backups を使用してバックアップを作成し、復元しましたか？
両方のシステムでホスト名が正しく設定されていますか？
「いいね！」 3
ありがとうございます。簡単そうに見えました。アプリに入力して実行しましたが、投稿内のURLのインスタンスは変更されていないようです。
リマップは次のとおりでした。
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
これは実行され、「default」DBで完了しました。数分かかり、エラーなしで「完了」と報告されました。
いくつかの投稿を確認しましたが、投稿のURLリンクには何も変更されていないようでした。
dev.domain.com がライブの domain.com の代わりにリンクに表示されているのをテストするためにいくつか再構築しましたが、それらは同じままでした。
次に、https:// を付けずに同じものを実行したところ、次のエラーが発生しました。
Remapping tables on default...
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
おそらく、DB内のチャットメッセージが原因で停止しているのだと思いますが、理由はわかりません。DBでそれを確認する方法が必要だと思います。ご存知のとおり、私の通常のDiscourse管理はDBには関与していません。
最後に、元のリマップを再度実行しました。数分かかり、「完了」と報告され、エラーはありませんでした。
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
結果を確認するには、投稿を再ベイクする必要があるかもしれませんか？
投稿の再構築は、投稿ごとに行われる同じアクションだと思っていました。
または、アプリを再構築しますか？
それは以下であるべきです
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
// の理由は、http://、https://、およびプロトコルなしの URL に一致し、電子メールアドレスのドメインには一致しないためです。
それを実行するとどうなりますか？
「いいね！」 2
はい、わかりました。同じエラーが再度発生しました。
デフォルトでテーブルを再マッピング中...
エラー: ERROR: 重複キーの値は一意制約 "index_post_hotlinked_media_on_post_id_and_url_md5" に違反しています
詳細: キー (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) は既に存在します。
上記のエラーにより、再マッピングは部分的にしか適用されませんでした。スクリプトを再度実行してください。
少なくとも正しい書き込みコマンドを使用しているようです。状況は好転しています！
他にアイデアはありますか？
このRailsのリマップの行き詰まり以外に、データベースをバックアップして再度リストアすれば、リストアプロセス中にLink-urlsが正しくリマップされるのではないかと思いました。
発生しているエラーは、以前修正が必要だった停止エラーと繰り返しまたは非常に類似しているようです。
Error: ERROR: duplicate key value violates unique constraint \"index_post_hotlinked_media_on_post_id_and_url_md5\"
DETAIL: Key (post_id, md5(url::text))=...
リマップを試したとき：
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
@david さんなら何か洞察があるかもしれませんか？
これはバグのように見えますか？
そのテーブルには両方のドメインのリンクが含まれているため、それらをリマップしようとすると重複したキーが生じます。これはバグではありません。あなたは重複したキーを作成しようとしています。
そのテーブルからアペックスドメインを持つアイテムを削除することもできますが、より良い方法は、アペックスドメインの代わりに www を使用することです。
「いいね！」 1
ありがとうございます。私の唯一の懸念は、このディスコースのデプロイメントも、例えば How to add ssl to non-www domain? のような非www/SSLの問題を抱えていることです。しかし、あなたが提案したリマップを試してみます。もしそれがうまくいけば、非wwwの問題も解決しなければならなくなります！
リマップの再考は @pfaffman が提案した通りに機能しましたが、実際には解決策そのものではなく、解決策の触媒となりました。何が間違っていたのかを理解するのに役立ち、私の目をリマップしてくれました！
エラーを正しく読んでいれば、つまり注意を払っていれば、エラーメッセージに重要な情報が含まれていることに気づいたはずなので、ずっと前にこれを解決できていたでしょう。
私がしなければならなかったのは、停止エラーでフラグが立てられた投稿番号 …/p/123456789 を URL に含めて、直接移動し、各投稿を手動で修正することでした。
これは、最初のマップの www を、元のニーズであった apex の非 www URL に変換するために、2回目のマップ実行で大部分が発生しました。
これで、内部 URL には apex リンクのみが含まれるはずです。
これは、多くのレガシー www 内部リンクがあった www SSL リダイレクトの一部を解決します。アドレスバーに www と入力した場合や、WWW 自体からのリンクバックは解決しませんが、内部で生成されたものはすべて対処できるはずです。この問題についてさらに何かを行う前に、Google インデックス作成にどのように影響するかを待っています。
開発者にとっては興味深いかもしれません。
duplicate key value violates unique constraint “unique_post_links” という重複キー値違反に関する多くの停止が見つかりました。これは、投稿が移動され、Discourse が「続きはこちら…」をホットリンクとして含めた場合に発生しましたが、分割された投稿に同じ場所への引用ブロックが含まれている場合、マップが停止しました。
これが停止エラーの大部分を引き起こしました。
解決策は、重複した内部リンクバックのいずれかを削除するか、コードで括弧で囲むことでした（常に機能したわけではありません）。マップを再実行すると、マップは続行されました。
その他の停止は、ユーザーが引用もリンクバックしていることに気づかずに、同じ投稿条件を手動で作成し、同じリンクを投稿に再度投稿したことによって引き起こされました。おそらく、歴史的な習慣、スタイルなどが関係しており、多くのユーザーが Discourse がリンクを処理して生活を楽にする方法をまだ理解していないことを示しています。皮肉なものです！
マップ後、編集を元に戻すこともできましたが、差が出るほど多くはなく、内部 Discourse ソースの投稿または引用への正しいリンクバックがまだ 1 つありました。
これが、数万ページが Google のインデックスから削除され、インデックス未作成の灰色の limbo に陥った大部分を逆転させることを願っています。
少しの知識は危険なものです！ 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.