Пользовательские эмодзи не используют CDN для ресурсов, хранящихся в S3, на нескольких страницах

Поддержка
1

Недавно я настроил свои установки Discourse на использование CDN и хранение загруженных файлов и ресурсов сайта в сервисе, совместимом с S3. Пока что всё остальное работает, но наши пользовательские эмодзи не загружаются.

При просмотре HTML-кода я заметил, что URL для одного из эмодзи выглядит так: //thrivecommunityforum.s3.eu-central-1.wasabisys.com/original/2X/6/6b7f95a2cfc7810d26c7e170ebf926ba8634261b.png
(он не загружается, так как я установил переопределение, чтобы запретить публичный доступ к бакету после того, как в файловом менеджере увидел предупреждение о включённой публичной записи для файлов).

В то же время все остальные загруженные изображения и ресурсы сайта корректно ссылаются на настроенный мной CDN: https://thrivecommunity-uploads.b-cdn.net/original/2X/6/62f6697da0e3cd71a7d4f1eed518641f8428150b.jpeg

URL встроенных эмодзи выглядят так: https://thrivecommunity-cdn.b-cdn.net/images/emoji/twitter/thinking.png?v=9

Таким образом, я прихожу к выводу, что, возможно, есть ошибка в обработке пользовательских эмодзи при генерации ссылок на изображения: она пропускает использование CDN, который настроен для работы перед файлами, хранящимися в S3.

Я попытался найти соответствующие темы, но нашёл только эту: Custom Emoji does not use Amazon S3, которая кажется устаревшей, так как Discourse пытается использовать S3 для обслуживания пользовательских эмодзи на моём сайте.

2

Пользовательские эмодзи для тестирования

:facepalm:

:mdr:

Обычные эмодзи

:slightly_smiling_face:

Таким образом, стандартные эмодзи используют один CDN, а пользовательские — другой, но оба покрываются CDN при правильной настройке в точном соответствии с использованием объектного хранилища для загрузок (S3 Clones).

Это не ошибка, а ожидаемое поведение, поскольку стандартные эмодзи хранятся внутри кода приложения, а пользовательские — как обычные загрузки сайта.

3

Я посмотрел эту тему, и насколько я могу судить, моя конфигурация должна быть верной:

  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

У меня была похожая проблема (посты с пользовательскими эмодзи не помечались для повторной обработки во время миграции на S3, если в исходном тексте поста не было других загрузок, и поэтому обработанная ссылка не указывала на CDN).

Я исправил это, удалив и снова загрузив одно из пользовательских изображений эмодзи. Это автоматически запустило задачу, которая перестроила все посты с пользовательскими эмодзи (но я уверен, что также существует rake-задача, которая может напрямую перестроить посты с пользовательскими эмодзи).

5

Я вижу проблему в admin/customize/emojis, а также в предпросмотре редактора постов. Кроме того, реакции-ответы на посты, созданные за последний час, не работают.
Таким образом, это затрагивает не только старые посты с эмодзи, но и новые посты, а также элементы интерфейса (выбор реакции-ответа также использует неверный URL, как и область управления эмодзи в админке).

6

Это связано с S3 CDN URL ignored when uploading into posts. Добавлено в оригинальную тему.

Пожалуйста, сообщайте о проблемах в теме плагина, так как это стороннее расширение.

Это действительно так, но эффект от этого невелик, так как это страница только для администраторов.

7

Действительно так. Если я опубликую сообщение, эмодзи отображается в нём корректно.

Если исправление для плагина Retort аналогично тому, как исправляется административная область, я, возможно, попробую исправить плагин, так как пользовательские эмодзи реакций широко используются на моём экземпляре Discourse.

8

Я попытался исправить это самостоятельно после краткого ознакомления.
Кажется, проблема в том, что метод JavaScript Discourse buildEmojiUrl получает URL хранилища вместо URL CDN для пользовательских эмодзи. Похоже, что плагин retort использует то же самое.
Так что, исправив это, мы, вероятно, решим все проблемы, верно?

После этого быстрого осмотра я нашел место, где, похоже, формируются URL для пользовательских эмодзи, и изменил его на следующее:

Я протестировал это через rails console, и это, кажется, исправляет URL на моём продакшн-сайте. Поэтому я попытался развернуть это изменение там, но оно не сработало.
После неудачи я также попробовал изменить EMOJI_VERSION на 10, чтобы попытаться что-то обновить, но это тоже не помогло. Когда я выполняю launcher enter и смотрю git log, я вижу свой коммит там. Я следовал подходу, описанному здесь: