Custom emoji don't use CDN for S3 stored assets in a few pages

I recently configured my discourse installs to use a CDN and store uploads and site assets in S3 compatible service. So far everything else has worked, but our custom emoji images fail to load.
When looking at the html I noticed that the URL for one of the emoji is //thrivecommunityforum.s3.eu-central-1.wasabisys.com/original/2X/6/6b7f95a2cfc7810d26c7e170ebf926ba8634261b.png
(this doesn’t load because I set an override to prevent public access to the bucket after seeing in the file manager a warning that public write was enabled for the files)
Whereas all the other uploaded images and site assets correctly reference the CDN I configured: https://thrivecommunity-uploads.b-cdn.net/original/2X/6/62f6697da0e3cd71a7d4f1eed518641f8428150b.jpeg

In-built emoji URLs look like this: https://thrivecommunity-cdn.b-cdn.net/images/emoji/twitter/thinking.png?v=9
So my conclusion is that there might be a bug in the custom emoji handling when generating the image links, which skips out on using the CDN that is configured to be in front of the S3 stored files.

I tried to find relevant topics, but I just found this: Custom Emoji does not use Amazon S3 which seems outdated as discourse is attempting to use S3 to serve custom emoji on my site.

1 Like

Custom emoji for testing

:facepalm:

:mdr:

Non custom emoji

:slightly_smiling_face:

So standard emoji use one CDN while custom use another, but both are covered by CDN if you do a proper configuration following Using Object Storage for Uploads (S3 Clones) to the letter.

Not a bug, this is expected behavior because standard emoji is stored inside the app codebase and custom is just a normal site upload.

3 Likes

I did have a look at that thread, and as far as I can tell my configuration should be right:

  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
1 Like

I had a similar problem (posts containing custom emojis weren’t marked for rebake during the migration to S3 if there were no other uploads in the raw post, and therefore the cooked link didn’t point to CDN).

I fixed it by deleting and reuploading just one of the custom emojis, and this automatically triggered a task which rebuilt all posts with custom emojis (but I’m sure there is also a rake task which can be used to rebake posts with custom emojis directly).

1 Like

I see the problem in admin/customize/emojis as well as in the post editor preview as well as retort reactions on posts done in the past hour fail.
So this doesn’t just affect old posts that use emoji, but also new posts and parts of the UI (the retort reaction picker also uses the wrong URL like the admin emoji management area).

1 Like

That is related to S3 CDN URL ignored when uploading into posts. Added to the original topic.

Please report on the plugin topic as it is third party.

This is legit, but low are of effect as it is an admin only page.

3 Likes

So it does. If I actually post, the emoji is shown correctly in it.

If the fix for the retort plugin is similar to how the admin area would be fixed, I could maybe give it a shot trying to fix the plugin as the custom reaction emojis are quite widely used on my discourse instance.

2 Likes

I tried fixing this myself after having a quick look.
It seems like the issue is that the discourse JavaScript method buildEmojiUrl receives the storage URL instead of the CDN URL for the custom emoji. Which seems to be the same thing retort plugin also uses.
So by fixing that, it would probably fix all of the problems, right?

After that quick look I found a place that seems to build the URLs for the custom emojis and I changed that to this:

I tested with rails console and that seems to fix the URLs on my production site. So I tried deploying that change there, however it didn’t work.
After that not working I also tried to change the EMOJI_VERSION to 10 to try to get something updating, but that didn’t work either. When I do launcher enter and git log I see my commit there. I followed the approach here:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.