Wow, was für eine Fahrt das war. Ich habe im Grunde meine gesamte Cloudflare R2-Objekt-Speicher- und Discourse-Instanz neu konfiguriert, und ich glaube, dieser Bug ist tatsächlich ein Problem bei R2. Als ich meinen Cloudflare-DNS-Eintrag korrigiert und die Instanz neu aufgebaut habe, sodass DISCOURSE_CDN_URL tatsächlich darauf zeigte, hat das eine ganze Menge anderer Dinge durcheinandergebracht, wie zum Beispiel Übersetzungsstrings, und mehrere Fehler in der Konsole verursacht, darunter einige CORS-Fehler. Das hat mich heute durch viele Kaninchenlöcher geführt. Also scheint die Verwendung von DISCOURSE_CDN_URL inkompatibel mit Cloudflare R2 zu sein. (Das war sehr seltsam – als ich ursprünglich meinen DNS-Eintrag eingerichtet habe, hatte ich den cdn.mysite.com-DNS-Eintrag falsch eingegeben, sodass er als cdn.mysite.com.mysite.com aufgelöst wurde.) Die korrekte Einstellung von DISCOURSE_CDN_URL scheint inkompatibel mit Cloudflare R2-Objekt-Speicher zu sein. Es gibt hier wahrscheinlich noch andere Dinge, die ich nicht vollständig verstehe.
Jedenfalls, wenn ich mit meinem PR-Branch neu aufbaue, ist alles behoben, weil es die Zuweisung in Discourse.store.cdn_url() einbettet, sodass Uploads benutzerdefinierter Emojis denselben S3-CDN-Routing- und Fallback-Logiken folgen wie Standard-Post-Bild-Uploads.
Ich habe den PR wieder geöffnet und die Beschreibung bearbeitet. Aber wenn das Discourse-Team entscheidet, ihn nicht zu mergen, ist das in Ordnung, da das Theme-Component das Problem auf Client-Ebene behebt. Beachte, dass die PR-Behebung nur R2-Objekt-Speicher-Konfigurationen für benutzerdefinierte Emojis betreffen sollte und nicht andere reguläre S3-kompatible wie AWS.