Impossible de le dire puisque tu as modifié ton post à la ninja sans créer de nouvelle révision. La première version de ce post ne contient que « edited.png ».
Cela me fait penser que tu as lié l’image plutôt que de la télécharger.
Oui, parce que tu as édité ton post trop rapidement. Nous avons ici une période de grâce de 300 secondes, durant laquelle, si tu effectues une modification, cela ne crée pas une nouvelle version du post.
Si tu regardes le code brut, tu verras que les images sont simplement des liens vers Dropbox.
Les liens sous-jacents ont été supprimés depuis longtemps. Cela ne devrait-il pas signifier que ces .gif devraient cesser d’apparaître ? Cliquer sur « Voir l’image » dans le menu contextuel m’emmène vers une adresse community.signalusers. Est-ce un comportement attendu ?
Test : je vais éditer ceci dans environ 300 secondes et supprimer le lien peu après.
deleted.png
Édition #2
Le lien est supprimé, mais l’image persiste dans l’historique des modifications. Peut-être n’a-t-elle pas d’enregistrement Upload car elle n’est pas supprimée par le nettoyage automatique.
Je suppose, en y réfléchissant, que le fait que l’image soit conservée localement est le comportement attendu lorsque l’option download_remote_images_to_local est activée. Je pense que c’est le paramètre pertinent.
Donc cela
ne fonctionne pas pour ce type de téléchargement, comme démontré dans mon message précédent. Corrigez-moi si je me trompe.
Le téléchargement sera supprimé si le paramètre du site « nettoyer les téléchargements » est activé, après la durée de grâce de « nettoyer les téléchargements orphelins en heures ».
Nettoyer les uploads semble être un paramètre général qui ciblerait toutes les images ayant un enregistrement upload, n’est-ce pas ? Pas uniquement celles présentes à cause de download_remote_images_to_local. Si c’est le cas, je devrais pouvoir trouver sur le site des exemples d’uploads d’images réguliers qui ne sont pas supprimés par le nettoyage automatique.
Vous dérangez-vous que je demande à quoi est réglé ici le paramètre clean orphan uploads grace period hours afin que je puisse le proposer comme solution ? Ou dispose-t-il d’une valeur par défaut ?
Si ils décident d’activer ce paramètre, devront-ils faire quelque chose pour l’appliquer aux publications passées ?
Édition
Juste pour être explicite, l’idée ici est qu’il ne s’agit pas d’un problème, mais qu’un paramètre doit être activé. Je ne veux simplement pas revenir en arrière pour dire « Vous devez activer cela ! » et qu’ils répondent « C’est déjà activé ! ». Je passerais pour un idiot.
Je me suis aussi surpris à chercher frénétiquement un endroit pour parcourir les fichiers uploadés (je connais bien cette fonctionnalité grâce à MediaWiki), car je sais pertinemment que les fichiers sont souvent uploadés en double, en triple, voire en quadruple. Parfois, je me demande où se trouve un fichier que j’ai uploadé il y a quelque temps, mais que j’ai peut-être perdu ou supprimé, afin de pouvoir y faire un lien plutôt que de le re-uploader encore une fois… Je suppose qu’il y a quelque chose à dire en faveur d’un navigateur de fichiers…
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
