waouh, quelle aventure. j’ai essentiellement reconfiguré tout mon stockage d’objets Cloudflare R2 et mon instance Discourse, et je pense que ce bug est bien réel pour R2. lorsque j’ai corrigé mon enregistrement DNS Cloudflare et reconstruit l’instance afin que DISCOURSE_CDN_URL pointe correctement vers lui, cela a cassé un tas d’autres choses, comme les chaînes de traduction, et a généré plusieurs erreurs dans la console, y compris des erreurs CORS. cela m’a mené dans de nombreux culs-de-sac aujourd’hui. donc, apparemment, utiliser DISCOURSE_CDN_URL semble incompatible avec Cloudflare R2. (c’était très étrange — lorsque j’ai initialement configuré mon enregistrement DNS original, j’avais incorrectement entré l’enregistrement DNS cdn.monsite.com de sorte qu’il résolvait en cdn.monsite.com.monsite.com). définir correctement DISCOURSE_CDN_URL semble incompatible avec le stockage d’objets Cloudflare R2. il y a peut-être d’autres aspects que je ne comprends pas entièrement ici.
bon, lorsque je reconstruis avec ma branche PR, tout est corrigé car elle enveloppe l’attribution dans Discourse.store.cdn_url() afin que les téléchargements d’emojis personnalisés respectent la même logique de routage CDN S3 et de repli que les téléchargements d’images de publication standards.
j’ai rouvert la PR et modifié la description. mais si l’équipe Discourse choisit de ne pas la fusionner, ce n’est pas grave car le composant thème corrige le problème au niveau client. Notez que la correction de la PR ne devrait affecter que les configurations de stockage d’objets R2 pour les emojis personnalisés et non les autres configurations compatibles S3 comme AWS.