その通りです。
あなたの投稿を編集して新しいリビジョンを作成しなかったため、判断できません。この投稿の最初のバージョンには「edited.png」しか含まれていません。
anon47420739:
Dropbox 側のリンクを削除すると、すぐに投稿内での表示が停止しました。
それにより、あなたは画像をアップロードしたのではなく、リンクを貼っただけだと推測されます。
anon47420739:
テストのためにペンのアイコンがありません:
はい、投稿を素早く編集したためです。ここでは 300 秒の猶予期間が設けられており、その間に編集を行っても、投稿の新しいバージョンは作成されません。
生データ(raw)を見ると、画像は単に Dropbox へのリンクであることがわかります。
これらはアップロードされたのではなく、リンクされただけです。
ありがとうございます。
元となるリンクはすでに削除されています。つまり、これらの .gif は表示されなくなるべきではないでしょうか?コンテキストメニューから「画像を表示」をクリックすると community.signalusers のアドレスに移動しますが、これは想定された動作ですか?
テストとして、約 300 秒後にこれを編集して削除し、その後すぐにリンクも削除します。
deleted.png
編集 #2
リンクは削除されましたが、画像は編集履歴に残っています。おそらく、自動クリーンアップによって削除されないため、Upload レコードが存在しないのでしょう。
https://d11a6trkgmumsb.cloudfront.net/original/3X/1/0/101f03af29f12ea30e1226eb96a02c3ed2f6d2ef.png にホストされています。Dropbox ではありません。
調べてみると、download_remote_images_to_local が有効になっている場合、画像がローカルに保持されるのは意図した動作のようです。これが関連する設定だと思います。
なので、この
という動作は、この種類のアップロードでは機能していないようです。これは前の投稿で示した通りです。間違っていたら教えてください。
Falco
(Falco)
2020 年 10 月 2 日午後 7:43
25
サイト設定「アップロードのクリーンアップ」が有効になっている場合、アップロードは「孤児アップロードの猶予期間(時間)」経過後に削除されます。
素早い返信をありがとうございます!
「アップロードのクリーンアップ」は、upload レコードを持つすべての画像を対象とする一般的な設定という意味で合っていますか?download_remote_images_to_local によって追加された画像に限らず、です。もしそうなら、自動クリーンアップによって削除されていない通常の画像アップロードの例をサイトで見つけることができるはずです。
「孤児アップロードの猶予期間(時間)」が何に設定されているか教えていただいてもよろしいでしょうか?解決策として提案したいので。あるいは、デフォルト値が設定されているのでしょうか?
もしその設定を有効にする場合、過去の投稿にも適用するために何か追加の操作が必要でしょうか?
編集
明確にするために付け加えますが、ここでの考え方は「これは問題ではなく、設定をオンにする必要がある」ということです。単に「これを有効にする必要があります!」と伝えて、相手が「すでに有効です!」と言われたら恥ずかしい思いをするのが嫌なので、確認しています。
sebastianh
(Rebastion)
2020 年 10 月 29 日午後 10:19
27
自分でも、アップロードされたファイルを閲覧できる場所を必死に探している自分に気づきました(MediaWiki ではおなじみの機能です)。ファイルが二重、三重、さらには四重にアップロードされてしまうことはよくあるからです。また、以前にアップロードしたファイルの場所がわからなくなったり、削除されてしまったりして、再アップロードする代わりにそのファイルへのリンクを貼りたいと思うこともあります……やはり、ファイルブラウザの存在意義は大きいのでしょうね……
tanius
2022 年 7 月 10 日午後 12:26
28
アップロードされたファイルをどうにかして削除する必要もありました。一部のファイルは別のフォーラムソフトウェアからのインポートによるもので、インポートされた投稿でまだ正しく参照されていないため、クリーンアップタスクは有効にしていません。そのため、手動で削除する方法を見つける必要がありました。以下は、見た目は良くありませんが機能する方法です…
関連するアップロードが、現在の投稿のバージョンに存在しないことを確認します。これにより、Discourse はそれを孤立したファイルとみなし、削除時に問題を起こしません。
Data Explorer プラグイン または別の方法を使用して Discourse データベースをクエリし、孤立したアップロードを一覧表示し、関連するものを特定して、その upload_id と filename をメモします。関連するクエリは次のとおりです。
SELECT
uploads.id, uploads.user_id, uploads.created_at,
uploads.url, uploads.filesize
FROM uploads
LEFT OUTER JOIN post_uploads ON uploads.id = post_uploads.upload_id
WHERE post_uploads.post_id IS NULL
ORDER BY created_at DESC
LIMIT 100
データベースまたは Rails console for Discourse を使用して、uploads テーブルから該当するレコードをその upload ID で削除します。ここでは Rails console を使用します。
Upload.where(id: 16384).first.delete
関連するファイル(最適化されたバージョンがあればそれらすべて、画像に適用されます)を SSH 経由でファイルシステムから削除します。ファイル拡張子の前にワイルドカードを追加して、ここにサフィックスが付く最適化されたバージョンもキャッチできるように注意してください。もちろん、
cd /path/to/discourse/shared/public/
find . -name 43adade7a4cc64426adb8232a56cb2c3b49fb7c9*.pdf -type f -delete
へえ!この投稿で参照されている画像は、これらの設定ではキャプチャされていないようです。
なぜ削除されなかったのでしょうか?
また、DropboxリンクのようなリンクされたファイルをDiscourseが「アップロード」するのはなぜでしょうか?特定のファイルをリンクする目的は、多くの場合、コンテンツの管理を維持することです。
post_uploads を upload_references にリネームしたことにより、ステップ 2 に記載されている SQL クエリは無効になりました。更新されたコードは次のとおりです。
SELECT
uploads.id, uploads.user_id, uploads.created_at,
uploads.url, uploads.filesize
FROM uploads
LEFT OUTER JOIN upload_references ON uploads.id = upload_references.upload_id
WHERE upload_references.target_id IS NULL
ORDER BY created_at DESC
LIMIT 100