Can’t tell since you ninja edited your post which did not create a new revision. The first version of this post only has “edited.png”.
Which makes me think that you linked the image and did not upload it.
Yes, because you edited your post too quickly. We have a grace period window of 300 seconds here in which if you make an edit, it won’t create a new version of the post.
If you look at the raw, you see that the images are merely links to dropbox
The underlying links have long been deleted - Shouldn’t that mean these .gif should seize appearing? Clicking “View Image” from the context menu takes me to a community.signalusers address, is that expected behavior?
Testing, I’ll edit this out in ~300 seconds and shortly after delete the link.
deleted.png
Edit#2
The link is deleted but the image persists in the edit history, perhaps it doesn’t have an Upload record as it isn’t removed by the automatic cleanup.
I suppose, looking about, that it is held locally is expected behavior when download_remote_images_to_local is enabled. I think that’s the relevant setting.
So this
isn’t functioning for this type of upload, as demonstrated in my previous post. Correct me if I’m wrong.
clean up uploads sounds like a general setting that would capture all images with an upload record, is that correct? Not just those present due to download_remote_images_to_local. If true, I should be able to find examples on the site of regular image uploads that aren’t being removed as a result of the automatic cleanup.
You mind me asking what the clean orphan uploads grace period hours is set to here so I can offer it as a solution. Or does it come with a default?
If they decide to enable that setting, will they need to do anything to apply it to past posts?
Edit
Just for the sake of being explicit, the thinking here is that this isn’t an issue but that a setting needs to be switched on. I just don’t want to go back and say “You need to enable this!” and they say “It is enabled!” I’ll look silly.
I also caught myself frantically looking for a place to browse uploads (familiar with it from MediaWiki) because I just know stuff gets double triple and quadruple uploaded, and sometimes I wonder where a file was that I uploaded once a while ago but maybe lost or deleted so I can link to it instead of re-uploading it yet again… I guess there is something to be said about a file browser…
J’ai également dû supprimer un fichier téléchargé. Nous n’avons pas activé la tâche de nettoyage car certains fichiers proviennent d’une importation d’un autre logiciel de forum et ne sont pas encore correctement référencés dans les publications importées. J’ai donc eu besoin de trouver une méthode manuelle. Ce qui suit fonctionne, mais ce n’est pas idéal…
Assurez-vous que le téléchargement pertinent n’est plus présent dans la version actuelle d’aucune publication. De cette façon, Discourse le considérera comme orphelin et ne causera pas de problèmes lors de sa suppression.
Utilisez le plugin Data Explorer ou une autre méthode pour interroger la base de données Discourse afin de lister les téléchargements orphelins, de trouver celui qui vous intéresse et de noter son upload_id et son nom de fichier. Requête pertinente :
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
Dans la base de données ou avec la console Rails pour Discourse, supprimez l’enregistrement concerné de la table uploads par son ID de téléchargement. Ici, j’utilise la console Rails :
Upload.where(id: 16384).first.delete
Supprimez le fichier associé, y compris toutes les versions optimisées (le cas échéant, s’applique aux images) du système de fichiers via SSH. Notez le caractère générique ajouté avant l’extension du fichier pour également capturer les versions optimisées, qui ont un suffixe ici. Bien sûr,
cd /path/to/discourse/shared/public/
find . -name 43adade7a4cc64426adb8232a56cb2c3b49fb7c9*.pdf -type f -delete
Hein ! Il semble que l’image référencée dans ce message ne soit pas capturée par ces paramètres :
Pourquoi n’a-t-elle pas été supprimée ?
Puis-je aussi me demander pourquoi Discourse « télécharge » un fichier lié comme le lien Dropbox ici ? L’objectif de lier un fichier spécifique est souvent de conserver le contrôle sur le contenu.
Avec le changement de renommage de post_uploads en upload_references, la requête SQL indiquée à l’étape 2 n’est plus valide. Le code mis à jour est :
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
