設定/法的情報のセクションで、別ホストのFAQページへのURL（おそらく利用規約およびプライバシーポリシーページへのURLも同様）が、フォーラムのランディングページで機能しなくなったようです。
他のWebページを指すいくつかのテスト用URLを試しましたが、現在はいずれも何も反応しません。また、私のフォーラムのランディングページでは、常にlogin_required.welcome_messageテキストが表示されるようになりました。以前は、指定されたURLのFAQページが表示されていました。
これらのカスタムページがDiscourse内の投稿として公開され、パブリックに設定されている場合、ログインが必要なダイアログに同じページへの手動リンクを配置することは依然として可能です。
この問題は解決しましたか？私のテストサイトでは、tos url と privacy policy url の設定を外部サイトへ向けることができています。外部リンクがサイト内のサインアップモーダルや「About」ページで無視されるような問題は見当たりません。
こんにちは、Simonさん。
この問題は私には解決せず、結局はよくある質問（実際にはサイト内の公開された「公開」ページです）から直接、ウェルカムダイアログのテキストにコピー＆ペーストしました。あまり効率的ではありませんが、機能しています。
興味深いことに、サインアップをクリックすると、利用規約とプライバシーポリシー（これも公開されたページです）へのリンクがサインアップダイアログからまだ機能していました。そのため、私の問題はランディングページに限定されているようです。
FAQ ページが、ページとして公開された Discourse トピックであることをおっしゃっているのでしょうか？もしそうなら、私はそのようなことは試したことがありません。
こんにちは、はい、その通りです。
アップグレード中に、事前に設定されたトピックがすべて消えてしまったため、他に選択肢がありませんでした。以前は問題なく動作していましたが、最近のアップグレード以降、ランディングページからそれらが機能しなくなりました。
あら、それは大変でしたね。TOS（利用規約）ページや FAQ ページに公開ページを使用していた理由を尋ねようとしていましたが、今ではその理由がわかります。ただし、これらのトピックに公開ページを使用するのはあまり理想的ではないようです。事前設定済みトピックを再作成することは可能だと確信しています。これらは一部の非表示のサイト設定によって制御されています。利用規約とプライバシーに関するトピックをリセットするために、以下の設定を使用できます。
tos_topic_idprivacy_topic_idFAQ トピック ID を設定する設定名は現時点では不明ですが、この変更を行いたい場合は、その設定を特定してご案内することも可能です。私の理解では、スタッフカテゴリに新しいトピックを作成し、そのトピック ID を非表示のサイト設定に割り当てる必要があります。
シモン、ありがとうございます。それがわかると助かります。
もしFAQのトピックIDを特定できるなら、それもぜひお願いします。同じように、事前設定されたトピックが壊れてしまう問題に直面する他の人たちのためにも、役立つはずです。
ランディングページの問題については、数日前にそれを一種のメリットに変える形で、FAQのより短いバージョンを作成しました（主に、自分が正しい場所にいるか確認したい人のためです）。そして、その下部には、完全版のFAQスタッフトピック、TOSスタッフトピック、プライバシーポリシートピックへのリンクを配置しました。
以前は、私のFAQはランディングページ全体を占めており（ウェルカムダイアログのテキストを置き換えていました）。
FAQ トピックに関連するサイト設定名は guidelines_topic_id です。
私はこの投稿で見つけました：How to fix faq, privacy policy and tos page? - #3 by rieko
まず、古い利用規約（TOS）、プライバシーポリシー、FAQ のトピックが存在するか確認するのが良いかもしれません。Rails コンソールから各サイト設定の値を確認し、UI を通じて削除されたトピックが見つかるか確認してください。
tos_topic_idprivacy_topic_idguidelines_topic_id各設定から返された ID を使って、/t/-/<設定値から取得したトピック ID> にアクセスすることで削除されたトピックを探せます。トピックが存在すれば、ユーザーインターフェースを通じて復元できるはずです。もしトピックが存在しない場合、Staff カテゴリに新しいトピックを作成すればよいと考えられます。その後、上記で挙げた各設定の値として、作成したトピックの ID を設定できます。私は実際に試したことはありませんが、もし貴方のサイトでの変更が不安な場合は、私のローカル開発環境でテストすることも可能です。
ありがとう、サイモン。
なるほど、理にかなっているね。その提案に対応するには、自分自身をRailsの知識を十分に身につける必要があるな。
ポール、どうでしたか？これは以前からあなたにとって問題だったことを覚えています。
私もつい最近、誤ってFAQ/ガイドラインのトピックでdelete_allを使用してしまい、しばらくの間それに気づきませんでした。この投稿は非常に役立ちました。
もし手助けが必要なら、喜んでご案内します。
見つからなかったプリシードトピックはありましたが、回避策には満足しているので、あまり熱心に試す気にはなりませんでした。基本的に、それらは現在、従来通り編集可能なスタッフのトピックであり、公開としてマークされており、時々更新できます。
サーバーのrootアクセスがあると仮定すると、修正は文字通り5分で完了し、便利なスタッフのトピックなどは失われません。
これを行うのは、使用するトピックとしてそれらを特定するためだけです。
レールを使うことについては何も知らないと告白しますが、データエクスプローラーのクエリ（現在見つけられない他のユーザーの提案による）を使用して、元のトピックが実際になくなったことを確認できました。
私が確認した限りでは、私のセットアップは、現在見つけられない方法論（これも現在見つけられない！）がレール編集ルートよりも少しハードコアではなかったとしても、使用すべきスタッフのトピックがどれであるかを「知って」いるようです。