J’ai récemment configuré mes installations Discourse pour utiliser un CDN et stocker les fichiers joints et les ressources du site dans un service compatible S3. Jusqu’à présent, tout fonctionne, sauf que nos émojis personnalisés ne se chargent pas.
En examinant le code HTML, j’ai remarqué que l’URL d’un des émojis est //thrivecommunityforum.s3.eu-central-1.wasabisys.com/original/2X/6/6b7f95a2cfc7810d26c7e170ebf926ba8634261b.png
(cette URL ne fonctionne pas car j’ai défini une surcharge pour empêcher l’accès public au bucket, après avoir vu dans le gestionnaire de fichiers un avertissement indiquant que l’écriture publique était activée pour les fichiers).
Tandis que toutes les autres images téléchargées et les ressources du site font correctement référence au CDN que j’ai configuré : https://thrivecommunity-uploads.b-cdn.net/original/2X/6/62f6697da0e3cd71a7d4f1eed518641f8428150b.jpeg
Les URL des émojis intégrés ressemblent à ceci : https://thrivecommunity-cdn.b-cdn.net/images/emoji/twitter/thinking.png?v=9
Ma conclusion est donc qu’il pourrait y avoir un bug dans la gestion des émojis personnalisés lors de la génération des liens d’image, ce qui fait que le CDN configuré pour se situer devant les fichiers stockés sur S3 n’est pas utilisé.
J’ai essayé de trouver des sujets pertinents, mais je n’ai trouvé que celui-ci : Custom Emoji does not use Amazon S3, qui semble obsolète, car Discourse tente d’utiliser S3 pour servir les émojis personnalisés sur mon site.
Les émojis standards utilisent donc un CDN, tandis que les émojis personnalisés en utilisent un autre, mais les deux sont couverts par le CDN si vous configurez correctement le système en suivant à la lettre le guide Utiliser le stockage objet pour les téléchargements (clones S3).
Ce n’est pas un bug, c’est un comportement attendu car les émojis standards sont stockés dans le code de l’application, tandis que les émojis personnalisés sont simplement des téléchargements normaux sur le site.
J’ai rencontré un problème similaire (les publications contenant des emojis personnalisés n’étaient pas marquées pour être retravaillées lors de la migration vers S3 s’il n’y avait aucun autre téléchargement dans le texte brut de la publication, et donc le lien généré ne pointait pas vers le CDN).
Je l’ai résolu en supprimant et en téléchargeant à nouveau un seul des emojis personnalisés, ce qui a automatiquement déclenché une tâche ayant reconstruit toutes les publications avec des emojis personnalisés (mais je suis certain qu’il existe également une tâche Rake permettant de retravailler directement les publications contenant des emojis personnalisés).
Je vois le problème dans admin/customize/emojis, ainsi que dans l’aperçu de l’éditeur de message. De plus, les réactions de réponse sur les messages publiés au cours de la dernière heure échouent.
Cela ne concerne donc pas uniquement les anciens messages utilisant des émojis, mais aussi les nouveaux messages et certaines parties de l’interface utilisateur (le sélecteur de réactions de réponse utilise également la mauvaise URL, tout comme la zone de gestion des émojis dans l’administration).
Effectivement. Si je publie réellement, l’émoji s’affiche correctement.
Si la correction pour le plugin Retort est similaire à celle qui serait appliquée dans la zone d’administration, je pourrais peut-être essayer de corriger le plugin moi-même, car les émojis de réactions personnalisés sont assez largement utilisés sur mon instance Discourse.
J’ai essayé de régler cela moi-même après un rapide coup d’œil. Il semble que le problème vienne du fait que la méthode JavaScript de Discourse buildEmojiUrl reçoit l’URL de stockage au lieu de l’URL du CDN pour les émojis personnalisés. Ce qui semble être la même chose que le plugin retort utilise également. Donc, en corrigeant cela, cela résoudrait probablement tous les problèmes, non ?
Après ce rapide coup d’œil, j’ai trouvé un endroit qui semble générer les URLs pour les émojis personnalisés et je l’ai modifié comme suit :
J’ai testé avec la console Rails et cela semble corriger les URLs sur mon site de production. J’ai donc essayé de déployer ce changement là-bas, mais cela n’a pas fonctionné.
Après cet échec, j’ai également essayé de modifier EMOJI_VERSION à 10 pour tenter de déclencher une mise à jour, mais cela n’a pas fonctionné non plus. Lorsque j’exécute launcher enter et git log, je vois bien mon commit. J’ai suivi la méthode décrite ici :
