Non posso dirlo, dato che hai modificato il tuo post in modo “ninja”, senza creare una nuova revisione. La prima versione di questo post contiene solo “edited.png”.
Questo mi fa pensare che tu abbia collegato l’immagine e non l’abbia caricata.
Sì, perché hai modificato il tuo post troppo rapidamente. Abbiamo una finestra di grazia di 300 secondi qui, durante la quale, se apporti una modifica, non viene creata una nuova versione del post.
Se guardi il codice sorgente, vedi che le immagini sono semplicemente link a Dropbox
I collegamenti sottostanti sono stati eliminati da tempo. Non dovrebbe significare che questi .gif dovrebbero smettere di apparire? Cliccando su “Visualizza immagine” dal menu contestuale vengo reindirizzato a un indirizzo community.signalusers; è questo il comportamento atteso?
Sto facendo una prova: modificherò questo messaggio tra circa 300 secondi e subito dopo eliminerò il collegamento.
deleted.png
Modifica #2
Il collegamento è stato eliminato, ma l’immagine persiste nella cronologia delle modifiche. Forse non ha un record di Upload, dato che non viene rimossa dalla pulizia automatica.
Immagino, guardando un po’ in giro, che sia un comportamento atteso quando download_remote_images_to_local è abilitato che le immagini siano conservate localmente. Credo che sia l’impostazione rilevante.
Quindi questo
non funziona per questo tipo di caricamento, come dimostrato nel mio post precedente. Correggetemi se sbaglio.
Il caricamento verrà eliminato se l’impostazione del sito pulisci caricamenti è abilitata, dopo il periodo di grazia per la pulizia dei caricamenti orfani in ore.
clean up uploads sembra un’impostazione generale che dovrebbe catturare tutte le immagini con un record upload, corretto? Non solo quelle presenti a causa di download_remote_images_to_local. Se è così, dovrei essere in grado di trovare esempi sul sito di caricamenti di immagini regolari che non vengono rimossi a seguito della pulizia automatica.
Ti dispiace se chiedo a quale valore è impostata qui la clean orphan uploads grace period hours così da poterne fare una soluzione? O ha un valore predefinito?
Se decidono di attivare quell’impostazione, dovranno fare qualcosa per applicarla ai post passati?
Modifica
Solo per essere espliciti, il ragionamento qui è che non si tratta di un problema ma che è necessario attivare un’impostazione. Non voglio solo tornare indietro e dire “Devi attivare questo!” e loro rispondere “È già attivo!” Sembrerei sciocco.
Mi sono anche ritrovato a cercare freneticamente un posto per sfogliare i caricamenti (familiare da MediaWiki) perché so che i file vengono caricati doppi, tripli e quadrupli, e a volte mi chiedo dove sia un file che ho caricato un po’ di tempo fa, ma che forse è stato perso o cancellato, così da poterlo linkare invece di ricaricarlo ancora una volta… Immagino che ci sia da dire qualcosa a favore di un browser per i file…
Ho anche dovuto in qualche modo eliminare un file caricato. Non abbiamo abilitato l’attività di pulizia poiché alcuni file provengono da un’importazione da un diverso software di forum e non sono ancora stati correttamente referenziati nei post importati. Quindi, ho dovuto trovare un modo manuale. Quanto segue funziona ma non è elegante…
Assicurati che il caricamento pertinente non sia più presente nella versione corrente di alcun post. In questo modo, Discourse lo considererà orfano e non creerà problemi quando lo elimini.
Utilizza il plugin Data Explorer o un altro modo per interrogare il database di Discourse per elencare i caricamenti orfani, trovare quello pertinente e annotare il suo upload_id e filename. Query 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
Nel database o con la console Rails per Discourse, elimina il record associato dalla tabella uploads tramite il suo ID di caricamento. Qui uso la console Rails:
Upload.where(id: 16384).first.delete
Elimina il file associato incluse tutte le versioni ottimizzate (se presenti, si applica alle immagini) dal file system tramite SSH. Nota il carattere jolly aggiunto prima dell’estensione del file per catturare anche le versioni ottimizzate, che qui hanno un suffisso. Naturalmente,
cd /path/to/discourse/shared/public/
find . -name 43adade7a4cc64426adb8232a56cb2c3b49fb7c9*.pdf -type f -delete
Huh! Sembra che l’immagine a cui si fa riferimento in questo post non sia catturata da queste impostazioni:
Perché non è stata eliminata?
Posso anche chiedermi perché Discourse “carica” un file collegato come il link di Dropbox qui? Il punto di collegare un file specifico è spesso quello di mantenere il controllo sul contenuto.
Con la modifica della ridenominazione di post_uploads in upload_references, la query SQL elencata nel passaggio 2 non è più valida. Il codice aggiornato è:
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
