Le emoji personalizzate non utilizzano la CDN per gli asset archiviati su S3 in alcune pagine

Supporto
1

Recentemente ho configurato le mie installazioni di Discourse per utilizzare una CDN e memorizzare gli upload e le risorse del sito in un servizio compatibile con S3. Finora tutto il resto ha funzionato, ma le nostre immagini di emoji personalizzate non riescono a caricarsi.

Dall’analisi dell’HTML ho notato che l’URL per una delle emoji è: //thrivecommunityforum.s3.eu-central-1.wasabisys.com/original/2X/6/6b7f95a2cfc7810d26c7e170ebf926ba8634261b.png
(Questo non funziona perché ho impostato un override per impedire l’accesso pubblico al bucket, dopo aver visto nel file manager un avviso che la scrittura pubblica era abilitata per i file)

Mentre tutte le altre immagini caricate e le risorse del sito fanno correttamente riferimento alla CDN che ho configurato: https://thrivecommunity-uploads.b-cdn.net/original/2X/6/62f6697da0e3cd71a7d4f1eed518641f8428150b.jpeg

Gli URL delle emoji integrate appaiono così: https://thrivecommunity-cdn.b-cdn.net/images/emoji/twitter/thinking.png?v=9

La mia conclusione è che potrebbe esserci un bug nella gestione delle emoji personalizzate durante la generazione dei collegamenti alle immagini, che omette di utilizzare la CDN configurata come front-end per i file memorizzati su S3.

Ho cercato argomenti pertinenti, ma ho trovato solo questo: Custom Emoji does not use Amazon S3, che sembra obsoleto, dato che Discourse sta tentando di utilizzare S3 per servire le emoji personalizzate sul mio sito.

2

Emoji personalizzate per i test

:facepalm:

:mdr:

Emoji non personalizzate

:slightly_smiling_face:

Quindi le emoji standard utilizzano un CDN, mentre quelle personalizzate ne usano un altro, ma entrambe sono coperte dal CDN se si esegue una configurazione corretta seguendo alla lettera Utilizzo dell’archiviazione oggetti per i caricamenti (cloni S3).

Non è un bug, questo è un comportamento previsto perché le emoji standard sono memorizzate all’interno del codice dell’applicazione, mentre quelle personalizzate sono semplicemente un normale caricamento sul sito.

3

Ho dato un’occhiata a quel thread e, per quanto posso vedere, la mia configurazione dovrebbe essere corretta:

  DISCOURSE_CDN_URL: https://thrivecommunity-cdn.b-cdn.net
  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: eu-central-1
  DISCOURSE_S3_ENDPOINT: https://s3.eu-central-1.wasabisys.com
  DISCOURSE_S3_INSTALL_CORS_RULE: false
  DISCOURSE_S3_ACCESS_KEY_ID: aaaa
  DISCOURSE_S3_SECRET_ACCESS_KEY: aaaa
  DISCOURSE_S3_CDN_URL: https://thrivecommunity-uploads.b-cdn.net
  DISCOURSE_S3_BUCKET: thrivecommunityforum
  DISCOURSE_S3_BACKUP_BUCKET: thrivecommunityforum-backup
  DISCOURSE_BACKUP_LOCATION: s3
4

Ho avuto un problema simile (i post contenenti emoji personalizzate non venivano contrassegnati per la ricottura durante la migrazione a S3 se non c’erano altri caricamenti nel post grezzo e, di conseguenza, il link cotto non puntava alla CDN).

L’ho risolto cancellando e ricaricando una sola delle emoji personalizzate; questo ha automaticamente attivato un’attività che ha ricostruito tutti i post con emoji personalizzate (ma sono sicuro che esista anche un task rake che può essere utilizzato per ricuocere direttamente i post con emoji personalizzate).

5

Vedo il problema anche in admin/customize/emojis, nell’anteprima dell’editor dei post e le reazioni di risposta sui post effettuati nell’ultima ora non funzionano.
Quindi questo non riguarda solo i vecchi post che utilizzano emoji, ma anche i nuovi post e parti dell’interfaccia utente (anche il selettore delle reazioni di risposta utilizza l’URL errato, come l’area di gestione delle emoji per gli amministratori).

6

Questo è correlato a S3 CDN URL ignored when uploading into posts. Aggiunto all’argomento originale.

Si prega di segnalare nell’argomento del plugin, poiché si tratta di un componente di terze parti.

Questo è legittimo, ma ha un impatto limitato poiché si tratta di una pagina riservata solo agli amministratori.

7

È vero. Se pubblico effettivamente, l’emoji viene visualizzata correttamente.

Se la correzione per il plugin Retort è simile a come verrebbe corretta l’area amministrativa, potrei provare a risolvere il problema del plugin, dato che le emoji delle reazioni personalizzate sono ampiamente utilizzate sulla mia istanza di Discourse.

8

Ho provato a risolvere il problema da solo dopo aver dato un’occhiata veloce.
Sembra che il problema sia che il metodo JavaScript di Discourse buildEmojiUrl riceve l’URL di archiviazione invece dell’URL CDN per le emoji personalizzate. Ciò sembra essere la stessa cosa che utilizza anche il plugin retort.
Quindi, correggendo questo, probabilmente risolverebbe tutti i problemi, giusto?

Dopo questa rapida occhiata, ho individuato un punto in cui vengono costruiti gli URL per le emoji personalizzate e l’ho modificato in questo:

Ho testato con la console di Rails e sembra che questo risolva gli URL sul mio sito di produzione. Quindi ho provato a distribuire questa modifica lì, ma non ha funzionato.
Dopo che non ha funzionato, ho anche provato a cambiare EMOJI_VERSION in 10 per tentare di forzare un aggiornamento, ma anche questo non ha funzionato. Quando eseguo launcher enter e guardo il git log, vedo il mio commit lì. Ho seguito l’approccio descritto qui: