Не могу сказать, так как вы скрытно отредактировали свой пост, не создав новую версию. В первой версии этого поста есть только «edited.png».
Это заставляет меня подумать, что вы просто вставили ссылку на изображение, а не загрузили его.
Да, потому что вы отредактировали свой пост слишком быстро. У нас есть временное окно в 300 секунд, в течение которого, если вы внесете правку, новая версия поста не будет создана.
Если вы посмотрите на исходный код, то увидите, что изображения — это просто ссылки на Dropbox.
Исходные ссылки уже давно удалены — не должно ли это означать, что эти .gif-файлы перестанут отображаться? При нажатии «Открыть изображение» в контекстном меню меня перекидывает на адрес community.signalusers. Это ожидаемое поведение?
Провожу тест: я отредактирую это сообщение примерно через 300 секунд, а вскоре после этого удалю ссылку.
deleted.png
Редактирование #2
Ссылка удалена, но изображение сохраняется в истории редактирования. Возможно, у него нет записи Upload, поэтому оно не удаляется автоматической очисткой.
Похоже, что при включённой настройке download_remote_images_to_local ожидаемо, что изображения хранятся локально. Думаю, это соответствующая настройка.
Так что это
не работает для такого типа загрузки, как показано в моём предыдущем сообщении. Поправьте, если я ошибаюсь.
Загрузка будет удалена, если в настройках сайта включена опция «Очистка загрузок», по истечении срока «Грациозный период для очистки сиротских загрузок (часы)».
«Очистка загрузок» звучит как общая настройка, которая должна захватывать все изображения с записью upload, верно? Не только те, что появились в результате download_remote_images_to_local. Если это так, я должен быть в состоянии найти на сайте примеры регулярных загрузок изображений, которые не удаляются в ходе автоматической очистки.
Не возражаете, если я спрошу, какое значение установлено для параметра clean orphan uploads grace period hours, чтобы я мог предложить его как решение? Или у него есть значение по умолчанию?
Если они решат включить эту настройку, нужно ли будет что-то делать, чтобы применить её к прошлым сообщениям?
Редактирование
Только для ясности: суть в том, что это не проблема, а настройку нужно просто включить. Я просто не хочу потом возвращаться и говорить: «Вам нужно включить это!», а в ответ услышать: «Оно уже включено!» — тогда я буду выглядеть глупо.
Я тоже поймал себя на том, что лихорадочно ищу место для просмотра загруженных файлов (знакомый интерфейс из MediaWiki), потому что знаю: файлы часто загружают дважды, трижды и даже четырежды. Иногда я задаюсь вопросом, куда делся файл, который я загружал какое-то время назад, но, возможно, потерял или удалил, чтобы я мог просто дать на него ссылку вместо того, чтобы загружать его снова… Думаю, есть смысл в обозревателе файлов…
Мне также пришлось каким-то образом удалить загруженный файл. У нас не включена задача очистки, так как некоторые файлы были импортированы из другого программного обеспечения для форумов и ещё не были корректно связаны с импортированными сообщениями. Поэтому мне нужно было найти ручной способ. Приведённый ниже метод работает, но выглядит не очень элегантно…
Убедитесь, что соответствующая загрузка больше не содержится ни в одной версии текущего сообщения. Тогда Discourse посчитает её «осиротевшей» и не создаст проблем при удалении.
Используйте плагин Data Explorer или другой способ для запроса к базе данных Discourse, чтобы вывести список «осиротевших» загрузок, найти нужную и записать её upload_id и имя файла. Соответствующий запрос:
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 для Discourse удалите соответствующую запись из таблицы uploads по её upload ID. Здесь я использую консоль Rails:
Upload.where(id: 16384).first.delete
Удалите соответствующий файл, включая все оптимизированные версии (если есть, касается изображений), из файловой системы через SSH. Обратите внимание на маску подстановки, добавленную перед расширением файла, чтобы также захватить оптимизированные версии, которые имеют здесь суффикс. Конечно,
cd /path/to/discourse/shared/public/
find . -name 43adade7a4cc64426adb8232a56cb2c3b49fb7c9*.pdf -type f -delete
Хм! Похоже, что изображение, на которое ссылается этот пост, не подпадает под эти настройки:
Почему оно не было удалено?
Могу ли я также спросить, почему Discourse «загружает» связанный файл, например ссылку на Dropbox здесь? Суть ссылки на конкретный файл часто заключается в сохранении контроля над контентом.
В связи с переименованием post_uploads в upload_references SQL-запрос, приведённый на шаге 2, больше не является корректным. Обновлённый код:
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
