Paul_King
(Paul King)
21
こんにちは。素人のやり方で、Data Explorer に以下のクエリを実行してみましたが、Staff カテゴリで削除されたメッセージに関連する結果は得られませんでした。
SELECT *
FROM topics
WHERE deleted_at is not NULL
AND category_id = 3
あるいは、どのカテゴリでも同様です。
SELECT *
FROM topics
WHERE deleted_at is not NULL
もしトピックが削除されていないのであれば、何か別の問題が起きているのでしょうか?削除されたトピックを検出する他の方法はあるでしょうか?それとも、システム投稿はそもそも topics テーブルに格納されていないのでしょうか?
nathank
(Nathan Kershaw)
22
Data Explorer のスキル、素晴らしいですね!
そのトピックは確かに topics テーブルにあります。
以下を試してみてください:
SELECT id, title, deleted_at
FROM topics
Order by id
Limit 10
以下のような結果が得られるはずです:
追伸:deleted_by_id の変更も必要になるかもしれません。
nathank
(Nathan Kershaw)
23
こんにちは @Paul_King さん、これを試されましたか?
Paul_King
(Paul King)
24
ありがとう、ネイサン。素晴らしい提案ですね。
ただし、削除されたトピックの中で最も低いトピック ID は 20 です
nathank
(Nathan Kershaw)
25
1 から 10 のいずれかをお持ちでしょうか?どうやらないようです。
サイトを一から再構築し、その後何らかの方法でデータベースをマージするのが解決策かもしれません。あるいは、Postgres をいじってみるのも手です!
Paul_King
(Paul King)
26
こんにちは、ネイサンさん。確かに削除されたトピックのリストは表示されていますが、スタッフカテゴリから欠けている事前にシードされたトピックは含まれていません。
Paul_King
(Paul King)
27
削除された痕跡もない、存在しなかった初期設定ポストを、データベースを直接いじることで取り消せるかどうか疑問に思っています。既存のインストールに対してセットアップウィザードを再実行して、それらの初期設定ポストを生成させる方法はあるでしょうか?セットアップウィザードが初回にそれらを省略してしまった可能性はあるでしょうか(もしかすると、初回に「スキップ」をクリックするオプションがあったのかもしれません)。
私がセットアップを行った当時のDiscourseバージョンにバグがあった可能性はあるでしょうか?
もし欠落している初期設定ポストが「削除済み」としてマークされているのではなく、単に存在しない場合、バックアップしたデータベースを新しいDiscourseインストールに復元しても、その欠落が伝播したり、既存データを上書きしたりすることはないでしょうか?それとも、起動時のデータベースが完全に削除され、バックアップ(その欠陥も含めて)に置き換えられてしまうのでしょうか?
riking
(Kane York)
28
もう一つ試す方法は、site_settings テーブルから tos_topic_id、guidelines_topic_id、privacy_topic_id を選択することです。
申し訳ありませんが、この SQL を使用してください:
SELECT value
FROM site_settings
WHERE name = 'tos_topic_id'
Paul_King
(Paul King)
29
Kane さん、ありがとうございます。
もしかしたら私のやり方が間違っているのかもしれませんが、私の環境では
SELECT tos_topic_id, site_settings
または(どちらが正しいか、あるいはどちらも正しくないか確信が持てませんが)
SELECT tos_topic_id
FROM
site_settings
を実行すると、
PG::UndefinedColumn: ERROR: column “tos_topic_id” does not exist
LINE 7: SELECT tos_topic_id, site_settings
というエラーが返ってきます。
これは「tos_topic_id」という列が存在しないという意味だと解釈しています。
guidelines_topic_id や privacy_topic_id についても同様の結果になります。
Paul_King
(Paul King)
31
ありがとうございます!!まさに私が探していたものです。ただ残念なことに、最後のrake topics:update_static[en]コマンドでエラーが発生してしまいました。なぜか、またどのように対処すればよいかはわかりません。
gerhard
(Gerhard Schlager)
32
エラーは何ですか?(サポートを求める場合は、エラーを共有するのがいつも良いアイデアです😉)
@Paul_King 私も update_static を実行した際にエラーが発生しましたが、FAQ ページは元に戻りました!
@gerhard エラーは以下の通りです。Paul さんも同じではないかと思います。
[5] pry(main)> rake topics:update_static[zh_CN]
NameError: undefined local variable or method `update_static' for main:Object
gerhard
(Gerhard Schlager)
34
Rails コンソールで rake タスクを実行しようとしていましたが、それは機能しません。正しく実行すると、rake タスクがもう存在しないことに気づくでしょう。
代わりに、シード済みカテゴリとトピックの更新 で説明されている「手動更新」方法を使用することをお勧めします。私は How to regenerate FAQ and TOS pages? - #2 by gerhard の手順をそれに応じて編集しました。
Paul_King
(Paul King)
35
サインアップダイアログのTOSとプライバシーポリシーのリンクを機能させる方法はありますか?上記の試みではうまくいきませんでしたが、リンクされていないTOSとプライバシーポリシーのトピックは作成できます。
これらのトピックが当初なぜ欠落していたのか、正確にはわかりません。欠落していることに気づいた際、うっかり削除してしまったものだと考えましたが、私の調査では、ユーザーインターフェース内ではそのようなことが起こりえないはずだと読み取れました。また、他のユーザーも同様の問題に直面していることから、どこかにバグが潜んでいる可能性はありますか?
nathank
(Nathan Kershaw)
36
ポールさん、最終的にどうなったかはわかりませんが、これで自分独自の利用規約やプライバシーポリシーページを作成できるようになりました:
https://meta.discourse.org/t/page-publishing/151971/31
Paul_King
(Paul King)
37
素晴らしい!ナタンの情報提供、ありがとう。これで問題解決しました。
公開された投稿に生成された URL を、設定/法的ページにある対応するフィールドにコピー&ペーストする必要があります。これらは「外部ホスト」された利用規約とプライバシーポリシーページとして扱われます。そうすれば、新しいサインアップダイアログ内のこれらのリンクが機能します。(なぜ FAQ がサインアップダイアログから除外されているのかはわかりませんが、この URL もここで設定できます。ただし、このフィールドの目的や、サインアップダイアログに含まれていない場合にどこからリンクされているのかは不明です。)
サイトが別の URL に移動するとこの回避策が機能しなくなる可能性がありますが、少なくともユーザーがサインアップ前に利用規約などを確認できるオプションを提供できるため、現時点では素晴らしい解決策です!