Benutzerdefinierte Emojis verwenden kein CDN für S3 gespeicherte Assets auf einigen Seiten

Unterstützung
1

Ich habe meine Discourse-Installationen kürzlich so konfiguriert, dass sie ein CDN verwenden und Uploads sowie Site-Assets in einem S3-kompatiblen Dienst speichern. Bisher hat alles funktioniert, aber unsere benutzerdefinierten Emoji-Bilder werden nicht geladen.
Beim Betrachten des HTML habe ich festgestellt, dass die URL für eines der Emojis wie folgt lautet: //thrivecommunityforum.s3.eu-central-1.wasabisys.com/original/2X/6/6b7f95a2cfc7810d26c7e170ebf926ba8634261b.png
(dies wird nicht geladen, da ich eine Überschreibung eingerichtet habe, um den öffentlichen Zugriff auf den Bucket zu verhindern, nachdem ich im Dateimanager eine Warnung gesehen habe, dass der öffentliche Schreibzugriff für die Dateien aktiviert war)
Während alle anderen hochgeladenen Bilder und Site-Assets korrekt auf das von mir konfigurierte CDN verweisen: https://thrivecommunity-uploads.b-cdn.net/original/2X/6/62f6697da0e3cd71a7d4f1eed518641f8428150b.jpeg

Die URLs für integrierte Emojis sehen so aus: https://thrivecommunity-cdn.b-cdn.net/images/emoji/twitter/thinking.png?v=9
Meine Schlussfolgerung ist daher, dass es möglicherweise einen Fehler in der Verarbeitung benutzerdefinierter Emojis gibt, der beim Generieren der Bildlinks das CDN überspringt, das vor den in S3 gespeicherten Dateien konfiguriert ist.

Ich habe versucht, relevante Themen zu finden, habe aber nur folgendes gefunden: Custom Emoji does not use Amazon S3 Dies scheint veraltet zu sein, da Discourse auf meiner Seite versucht, S3 zum Ausliefern benutzerdefinierter Emojis zu verwenden.

2

Benutzerdefinierte Emojis zum Testen

:facepalm:

:mdr:

Nicht benutzerdefinierte Emojis

:slightly_smiling_face:

Standard-Emojis verwenden also ein CDN, während benutzerdefinierte Emojis ein anderes nutzen. Beide sind jedoch durch ein CDN abgedeckt, wenn Sie eine ordnungsgemäße Konfiguration gemäß Using Object Storage for Uploads (S3 Clones) bis ins Detail durchführen.

Kein Fehler, dies ist das erwartete Verhalten, da Standard-Emojis im App-Code gespeichert sind und benutzerdefinierte Emojis lediglich normale Dateiladen der Site sind.

3

Ich habe mir den Thread angesehen, und soweit ich das beurteilen kann, sollte meine Konfiguration korrekt sein:

  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

Ich hatte ein ähnliches Problem (Beiträge mit benutzerdefinierten Emojis wurden während der Migration zu S3 nicht für eine Neubearbeitung markiert, wenn im Rohbeitrag keine anderen Uploads vorhanden waren, und daher zeigte der verarbeitete Link nicht auf das CDN).

Ich habe es behoben, indem ich eines der benutzerdefinierten Emojis gelöscht und neu hochgeladen habe. Dadurch wurde automatisch eine Aufgabe ausgelöst, die alle Beiträge mit benutzerdefinierten Emojis neu aufgebaut hat (aber ich bin mir sicher, dass es auch einen Rake-Befehl gibt, mit dem Beiträge mit benutzerdefinierten Emojis direkt neu bearbeitet werden können).

5

Ich sehe das Problem sowohl unter admin/customize/emojis als auch in der Vorschau des Beitragseditors. Zudem schlagen Reaktionen auf Beiträge, die in der letzten Stunde erstellt wurden, fehl.

Das betrifft also nicht nur alte Beiträge, die Emojis verwenden, sondern auch neue Beiträge und Teile der Benutzeroberfläche (der Retort-Reaktionsauswahl nutzt ebenfalls die falsche URL, genau wie der Bereich zur Emoji-Verwaltung im Admin-Bereich).

6

Das hängt mit folgendem Thema zusammen: S3 CDN URL ignored when uploading into posts. Ich habe es dem ursprünglichen Thema hinzugefügt.

Bitte melde dies im Plugin-Thema, da es sich um ein Drittanbieter-Plugin handelt.

Das ist berechtigt, hat aber nur geringe Auswirkungen, da es sich um eine Seite nur für Administratoren handelt.

7

Stimmt tatsächlich. Wenn ich etwas poste, wird das Emoji darin korrekt angezeigt.

Wenn die Korrektur für das Retort-Plugin ähnlich funktioniert wie die für den Admin-Bereich, könnte ich versuchen, das Plugin selbst zu beheben, da benutzerdefinierte Reaktions-Emojis auf meiner Discourse-Instanz ziemlich häufig verwendet werden.

8

Ich habe versucht, das Problem nach einem kurzen Blick selbst zu beheben.
Es scheint, dass die Diskurs-JavaScript-Methode buildEmojiUrl statt der CDN-URL die Storage-URL für benutzerdefinierte Emojis erhält. Das scheint dasselbe Problem zu sein, das auch das Retort-Plugin betrifft.
Wenn man das behebt, würden damit wahrscheinlich alle Probleme gelöst sein, oder?

Nach diesem kurzen Blick habe ich eine Stelle gefunden, an der die URLs für benutzerdefinierte Emojis erstellt werden, und habe sie wie folgt geändert:

Ich habe es über die Rails-Konsole getestet, und es scheint, dass die URLs auf meiner Produktionsseite dadurch korrekt erstellt werden. Ich habe daher versucht, diese Änderung dort bereitzustellen, doch sie funktionierte nicht.
Nachdem das nicht funktioniert hat, habe ich auch versucht, die EMOJI_VERSION auf 10 zu setzen, um eine Aktualisierung auszulösen, aber das hat ebenfalls nicht funktioniert. Wenn ich launcher enter ausführe und git log überprüfe, sehe ich meinen Commit dort. Ich habe dabei den Ansatz hier befolgt: