Dopo aver effettuato alcuni esperimenti, ho notato che alcuni dei miei post non visualizzano le immagini, nemmeno prima di eseguire alcuna operazione di ‘remap’.
Invece, mostrano una piccola icona dell’immagine, che rivela il percorso del file se ci passi sopra con il mouse e mostra l’immagine solo dopo averci cliccato.
Inoltre, anche quell’icona scompare (e al suo posto appare uno spazio bianco o un segnaposto per l’immagine) se eseguo ‘Rebuild Html’ dal menu a tre puntini, o anche se effettuo qualsiasi operazione di ‘rebake’ all’interno del contenitore.
Se non hai eseguito un remap e il tuo bucket S3 è ancora funzionante, nulla dovrebbe essere cambiato rispetto a prima. Quelle immagini funzionavano prima di iniziare questo percorso?
In teoria, perderai la connessione a quei file di immagini solo se disattivi il tuo bucket S3 o esegui il remap in modo errato.
Grazie.
Ho notato che l’icona dell’immagine mostra il percorso /bucket/uploads/optimized/folder/… (e poiché non esiste alcuna immagine a questo percorso, l’immagine non viene visualizzata, ma solo l’icona).
Tuttavia, quando faccio clic sull’icona dell’immagine, questa viene visualizzata/servita dalla cartella ‘Orig’, ovvero /bucket/uploads/original/…
Non capisco come una singola immagine possa avere due percorsi diversi memorizzati per essa?!!
Comunque, ora il problema è diventato: come posso trovare i post che hanno immagini mappate su un percorso errato (sotto ‘optimized’)? In modo da poter correggere/rimappare i loro indirizzi al percorso corretto sotto ‘Original’.
Grazie @nathank, @Pravi, @itsbhanusharma. Poiché ho confuso diversi problemi/scenari, attualmente mi trovo in questa situazione:
Alcuni dei miei post non mostrano le immagini caricate; invece, visualizzano solo una piccola icona con un URL/indirizzo del bucket errato quando passo il mouse sopra. Oppure, alcuni mostrano l’immagine corretta e il percorso del bucket corretto SOLO quando clicco su quelle piccole icone. E poi ci sono altri post le cui immagini non mostrano nulla, solo uno spazio bianco vuoto.
Inoltre, se eseguo un’operazione di rimappatura (remap wrongbucketurl correctbucketurl), ho scoperto in un post campione che, anche se per un attimo la piccola icona è stata sostituita dall’immagine corretta (e io ero felice), il giorno dopo quell’immagine è scomparsa completamente, senza nemmeno l’icona. Al suo posto è apparso solo uno spazio bianco. Quindi ho dovuto ripristinare il mio sito alla versione del giorno precedente.
Quando ho eseguito questo comando, il risultato è stato questo:
# rake posts:missing_uploads
Ricerca di upload mancanti su: default
19 upload di post sono mancanti.
19 upload sono mancanti.
6 su 7792 post sono interessati.
Ho eseguito delle varianti di questo processo alcune dozzine di volte e non funziona ancora.
Le nostre immagini non vengono visualizzate tramite S3 perché la direzione ha deciso di non voler avere un bucket S3 con accesso pubblico, quindi dobbiamo tornare all’archiviazione locale.
Inizialmente ho esaminato i link interrotti e da ciò sono riuscito a capire i valori da utilizzare nel rimappaggio (pensavo), e un bel po’ di immagini funzionano ora. Ma la maggior parte, direi oltre il 90%, non funziona. A differenza di quando si hanno link S3 interrotti e si possono almeno ispezionare per iniziare a capire cosa non va, qui ottengo solo questo:
Qualcuno sa cosa potrebbe causare il fallimento di queste immagini? Sono bloccato su questo da giorni. Trovo incredibile che a) non ci sia un modo per tornare indietro e b) qualcuno (non io) ci abbia migrato quando non esiste un modo per tornare indietro.
Per essere chiaro, ho seguito la procedura descritta sopra da @nathank. Ho provato molte volte, generalmente con piccole varianti nei percorsi durante il passaggio di rimappaggio, perché non è chiaro se quelle istruzioni siano universali o dipendano dall’aspetto della tua directory (la nostra ha diverse sottodirectory che sono state copiate con successo da S3 usando il passaggio di sincronizzazione S3).
Apprezzerei molto un aiuto, dato che sono sul punto di strapparmi i capelli.
Penso che quello che vuoi fare sia attivare la variabile nascosta include_s3_uploads_in_backups, eseguire un backup e poi ripristinarlo (ti consiglio di farlo prima su un nuovo server di test). Questo è esattamente ciò che accade quando un cliente di CDCK annulla l’abbonamento: i backup vengono ripristinati su un nuovo sito self-hosted senza alcun problema.
NoMethodError: metodo include_s3_uploads_in_backups=' non definito per SiteSettings:Module da (pry):1:in pry’
Poi ho capito che forse dovevo riattivare i caricamenti su S3, perché li avevo disattivati, ma ho ottenuto comunque lo stesso errore.
Ah, usiamo due container e sto eseguendo questo in web_only. Il comando Rails non viene trovato nel container dei dati, quindi suppongo che questo sia l’approccio corretto.
Ho eseguito questo comando e poi ho creato un nuovo backup. Dopo aver ripristinato da quel backup, non ho notato alcuna modifica: la maggior parte delle immagini mostra ancora l’icona rotta mostrata sopra. Ho anche provato a ricostruire entrambi i container, ma senza risultati.
Quando scarico ed esamino il file zip del backup, tutti quei file sono sicuramente presenti e, dopo il ripristino, sono visibili nel filesystem. Tuttavia, Discourse si rifiuta semplicemente di riconoscerli e visualizzarli.
Per la cronaca, alla fine sono riuscito a farlo funzionare. Ho ricominciato da capo (cioè da uno snapshot della mia istanza) e sono abbastanza certo che il processo che alla fine ha funzionato sia stato:
utilizzare la console rails per eseguire SiteSetting.include_s3_uploads_in_backups=true
creare un nuovo backup
ripristinare da questo backup
utilizzare discourse remap per aggiornare i riferimenti alle varie posizioni dei file S3 a una posizione locale
rifare il baking dei post e ricostruire entrambi i container Docker
Grazie @pfaffman per avermi indicato la direzione giusta.
MODIFICA
Potrei anche sollevare questa questione. Dopo il mio precedente messaggio, ho realizzato che sei dei nostri argomenti hanno ancora immagini rotte (anche se la stragrande maggioranza è ora a posto).
Si tratta dei nostri sei post più vecchi e tutte le immagini originali avevano un URL S3 diverso rispetto a tutte le altre. Chiaramente non è una coincidenza. Quindi ho verificato che tutti quei file fossero nella directory uploads/default/original/1X, e lo erano. Poi ho eseguito un comando remap utilizzando questo URL S3 unico e sembrava aver modificato il numero corretto di post. Quindi ho rifatto il baking e ricostruito i container, ma questi argomenti sono ancora rotti. Qualcuno ha idea del motivo per cui un piccolo numero fallisca in questo modo?
