عند استخدام S3 أو Cloudflare R2 للرفع إلى جانب عنوان URL مخصص لـ CDN، لا تحترم عمليات رفع الرموز التعبيرية (الإيموجي) المخصصة إعدادات الـ CDN، وتحاول التحميل مباشرة من عنوان URL الأصلي للحاوية (Bucket).
المشكلة
عندما يقوم المسؤول برفع رمز تعبيري مخصص، ينشئ نظام الرفع سجل upload ويحفظ عنوان URL الأصلي للحاوية في قاعدة البيانات (على سبيل المثال: //my-bucket.s3.amazonaws.com/... أو //my-bucket.r2.cloudflarestorage.com/...) — وهذا هو السلوك القياسي في Discourse.
ومع ذلك، عندما يقوم الملف app/models/emoji.rb بإنشاء ذاكرة التخزين المؤقت للرموز التعبيرية الخاصة بـ /site.json، فإنه يمرر upload.url مباشرة إلى كائن emoji:
e.url = emoji.upload&.url
وبما أنه يتخطى دالة مساعدة الـ CDN، يتلقى الواجهة الأمامية عنوان URL الأصلي للحاوية. لذلك، اعتمادًا على مدى صرامة سياسات الوصول الخاصة بالحاوية، يؤدي ذلك إلى ظهور صور معطلة أو يجبر Discourse على توجيه الرموز التعبيرية عبر avatar_proxy الداخلي.
الحل
لقد قمت بفتح طلب سحب (PR) يلتف حول تعيينات عناوين URL باستخدام Discourse.store.cdn_url()، مما يجعل محمل الرموز التعبيرية المخصصة يتماشى مع طريقة توجيه صور المنشورات الرمزية والصور الرمزية القياسية.
حل مؤقت
أثناء انتظار مراجعة طلب السحب ودمجه، قمت بإنشاء مكون سمة (Theme Component) خفيف الوزن يستبدل عنوان URL الأصلي للحاوية بعنوان CDN الصحيح مباشرة قبل عرض الرمز التعبيري المخصص في DOM (يعمل لكل من المنشورات والدردشة).
إذا كنت تواجه هذا الخطأ على موقعك، يمكنك تثبيت هذا المكون وتكوين سلاسل S3 الخاصة بك في إعدادات إدارة السمة لإصلاح أي رموز تعبيرية مخصصة معطلة:
ملاحظة: إذا كنت قد قمت بالفعل برفع رموز تعبيرية مخصصة وهي حاليًا معطلة، فإن تشغيل الأمر discourse remap "//my-raw-bucket-url.com" "https://my-cdn.com" داخل الحاوية (container) سيقوم بإصلاح القديمة منها في قاعدة البيانات، بينما سيقوم مكون السمة بإصلاح أي رموز جديدة يتم رفعها حتى يتم دمج إصلاح طلب السحب في النسخة الأساسية.
نعم، ربما يكون هذا الأمر خاصًا بخدمة Cloudflare R2 فقط. فهي تسبب مشاكل في نسختي. ويبدو أن المشكلة تحدث فقط مع الملفات المرفوعة حديثًا.
بدون إصلاح مكون الثيم، يجب أن أعمل عملية إعادة تعيين الروابط في كل مرة أرفع ملفًا جديدًا. قد يحتاج طلب الدمج (PR) إلى بعض التحسينات - لست خبيرًا في كود الرموز التعبيرية.
يستخدم Discourse إعدادًا يتضمن شبكتين لتوزيع المحتوى (CDN)، واحدة للموارد والأخرى تعمل كبروكسي للتطبيق.
تستخدم الرموز التعبيرية القياسية شبكة CDN واحدة، بينما تستخدم الرموز التعبيرية المخصصة الشبكة الأخرى، لكن كلاهما محمي بشبكة CDN في موقع إلكتروني مُعد بشكل صحيح مع إعداد يعمل لشبكتين لتوزيع المحتوى.
لقد غطيت ذلك في الموضوع الأول ذي الصلة هنا
هل يحتوي موقعك على إعداد شبكتين لتوزيع المحتوى وهما تعملان بشكل صحيح؟
لقد قمت بتعيينها بالفعل، لكن يا إلهي، كان لدي خطأ مطبعي في تكوين Cloudflare لسجل DNS الخاص بـ CDN الذي يشير إليه DISCOURSE_CDN_URL، ولم أجربه عندما قمت بإعداده لأن موقع الويب الخاص بي كان يعمل ما فوضى مروعة.
على الأقل تعلمت المزيد عن إنشاء رموز الإيموجي في ذلك الطلب غير المجدي…
واو، كانت هذه رحلة حقيقية. لقد أعدتُ تكوين نظام تخزين الكائنات Cloudfare R2 ووحدة Discourse بالكامل تقريبًا، وأعتقد أن هذا الخلل حقيقي فيما يتعلق بـ R2. عندما أصلحت سجل DNS الخاص بـ Cloudflare وأعددت بناء الوحدة بحيث يشير DISCOURSE_CDN_URL إليه فعليًا، تسبب ذلك في تعطيل العديد من الأشياء الأخرى مثل سلاسل الترجمة، وأدى إلى ظهور أخطاء متعددة في وحدة التحكم، بما في ذلك بعض أخطاء CORS. لقد قادني ذلك إلى العديد من المتاهات اليوم. لذا يبدو أن استخدام DISCOURSE_CDN_URL غير متوافق مع Cloudflare R2. (كان هذا غريبًا جدًا - عندما قمت بإعداد إدخال DNS الأصلي في البداية، أدخلت سجل DNS لـ cdn.mysite.com بشكل خاطئ بحيث كان يحل إلى cdn.mysite.com.mysite.com). يبدو أن ضبط DISCOURSE_CDN_URL بشكل صحيح غير متوافق مع نظام تخزين الكائنات Cloudflare R2. قد يكون هناك أمور أخرى لا أفهمها بالكامل هنا.
على أي حال، عندما أعيد البناء باستخدام فرع طلب السحب (PR) الخاص بي، يتم إصلاح كل شيء لأنه يلف عملية التعيين داخل Discourse.store.cdn_url() بحيث تتبع عمليات رفع الرموز التعبيرية المخصصة نفس منطق التوجيه والنسخ الاحتياطي لـ S3 CDN كما تفعل عمليات رفع صور المنشورات القياسية.
أعدتُ فتح طلب السحب وقمت بتعديل الوصف. ولكن يبدو أنه إذا قرر فريق Discourse عدم دمجه، فلا بأس بذلك لأن مكون السمة يحل المشكلة على مستوى العميل. لاحظ أن إصلاح طلب السحب يجب أن يؤثر فقط على تكوينات تخزين الكائنات R2 للرموز التعبيرية المخصصة، وليس على خدمات S3 المتوافقة الأخرى مثل AWS.
ما فوضى مروعة.