I have a question concerning CDN technology.
Am I right that cdn can only cache the files in my site and can’t cache hotlinked files from another site?
I store catalogue files (mps and pictures) on another server and hotlink them on my Discourse site. Am I right that such files won’t be cached by cdn? Is there a way to cache the hotlinked files too?
Unless you tell discourse not to, it will pull those remote images to its own image store. The below assumes you turned that off.
You should put that site behind CDN and then share the CDN url to discourse.
If you put a CDN in front of your image site but share the origin url to discourse, You can use a built in feature to replace the origin url with the CDN url .
Am I right, that if I activate the CDN feature in Discourse and switch off saving the origin to Discourse, the cdn service will cache these external files and Discourse will replace all the links to files hotlinked from another site?
I doubt that can caches external files hotlinked from other sites. Can anybody approve it?
FYI - I’ve posted a new thread on how to setup full site CDN acceleration (and SSL termination) using AWS Cloudfront here (link below). There be dragons here - so tread lightly.
هل ما زال هذا مطلوبًا عندما يحدث الخطأ Reason: CORS header ‘Access-Control-Allow-Origin’ missing؟
لا يمكنني العثور على أي شيء يستخدم هذا المتغير في Github:
تعديل: لا يزال تعليق الإعدادات يقول إنه مطلوب، وهو يعمل بعد ذلك. لذلك سأقبل الأمر 
في الوقت الحالي من عام 2023، هل لا تزال القواعد الأربع المذكورة أدناه بحاجة إلى اتباعها بدقة؟ على سبيل المثال، إذا كنت سأستخدم Akamai، المصمم لجعل اسم النطاق الرئيسي مع تسريع شبكة توصيل المحتوى الخاصة به. هل لدى أي شخص تكوين مُقطّر للقواعد المذكورة أدناه، مثل هل يجب أن يستمر طلب ناقل الرسائل و الاستقصاء الطويل إلى المصدر؟ أين يجب أن تذهب هذه الإعدادات؟ يبدو أن عنوان URL الأساسي للاستقصاء الطويل قد تمت إزالته من لوحة تحكم المسؤول؟
هناك بعض الإعدادات المتقدمة التي تسمح لك بتقديم طلبات Message Bus من مجال مختلف. ومع ذلك، فهي معقدة للغاية.
لذلك، يجب تعيين “عنوان URL الأساسي للاستطلاع الطويل” من خلال وحدة تحكم Rails. نظرًا لأنه تمت إزالته من لوحة تحكم المسؤول. يجب أن أكون قد فاتني السبب المنشور في أي مكان من قبل لماذا تمت إزالته إذا كان الإعداد لا يزال مطلوبًا لتمكين الموقع من العمل بشكل جيد في وضع شبكة توصيل المحتوى للموقع بالكامل.
وبالمثل، يجب تعيين DISCOURSE_ENABLE_CORS: true في app.yml.
يجب عليك تعيينه باستخدام متغير بيئة (DISCOURSE_LONG_POLLING_BASE_URL) في ملف app.yml الخاص بك. إنه مخفي لأن قلة قليلة من الأشخاص يحتاجون إلى تعيينه ويفترض أنه إذا كنت تفعل ذلك فأنت تعرف ما تفعله.
شكراً، @pfaffman! كان يجب أن أعرف أن كل هذه المتغيرات المكتوبة بأحرف كبيرة يجب أن توضع في app.yml.
إذن، ما هي حالات استخدام ناقل الرسائل التي ستدخل حيز التنفيذ؟ على سبيل المثال، الرد على منشور يسبب إشعارًا وما إلى ذلك؟ سأقوم باختبار حالات الاستخدام للتأكد مما إذا كان ناقل الرسائل في موقعي يعمل كما هو متوقع بدون تعيين DISCOURSE_LONG_POLLING_BASE_URL.
مرحباً،
هل تم إزالة “عنوان URL الأساسي للاستطلاع الطويل” من لوحة تحكم المسؤول؟ أو هل يمكن إجراء هذا الإعداد من خلال وحدة تحكم Rails؟
long_polling_base_url هو إعداد موقع مخفي، ولكن يمكن تعيينه من وحدة تحكم rails إذا لم تكن تستخدم متغير بيئة في app.yml الخاص بك:
هذه القائمة بالتأكيد تعطي رؤى أعمق حول Discourse.
لقد قمت بإعداد شبكة توصيل المحتوى (CDN) مع موقعي الإلكتروني، وقد وصلت إلى ذاكرة التخزين المؤقت للحافة، ومع ذلك لم أواجه مشكلة في ناقل الرسائل (message-bus) مع رؤوس الاستجابة الخاصة به، ولكن لا يزال الأمر لا يبدو قوياً. لم يتم تعيين إعدادات CORS أيضاً.
Cache-Control: must-revalidate, private, max-age=0
مرحباً،
لقد طرحت سؤالي في موضوع آخر Full Site CDN Using AWS CloudFront - #2 by Hyan. لقد قمت بنفس الإعداد وتركت #DISCOURSE_CDN_URL: https://discourse-cdn.example.com دون تغيير. هل يمكنني تعيين هذا إلى نفس عنوان URL للموقع؟ على سبيل المثال، http://forum.example.com. بخلاف ذلك، ستكون هناك أصول URL في مسار نسبي بدون اسم نطاق.
أقدر ذلك إذا أعطاني @sam أو @pfaffman تلميحاً.
لا أوصي باستخدام Cloudflare كشبكة توصيل محتوى (CDN). يستخدمها بعض الأشخاص. ربما يمكنهم المساعدة.
تحرير: أوه، آسف. هذه “شبكة توصيل محتوى للموقع بالكامل…” ربما لا ينبغي لي المساهمة هنا.
لا، أنا أستخدم Akamai CDN، الذي يدعم تخزين المحتوى الديناميكي مؤقتًا.
من المنشور الأول في هذا الموضوع، يبدو أنه يجب عليّ تعيين DISCOURSE_CDN_URL كـ CDN غير كامل للموقع، على الرغم من أن عنوان URL هو نفسه عنوان URL للموقع. أنا فقط لست متأكدًا مما إذا كان تعيينه يتسبب في تعطل موقعي ونتائج أخرى لا رجعة فيها، وفي النهاية اضطررت إلى إعادة تثبيت البرنامج من البداية. في هذا المنشور https://meta.discourse.org/t/full-site-cdn-using-aws-cloudfront/208161، لم يقم المؤلف بتعيينه ويترك DISCOURSE_CDN_URL دون تغيير، ولا يتطلب عنوان URL منفصلاً لخدمة message-bus/long-polling. أستخدم هذا الحل وموقعي يعمل بشكل جيد حتى الآن. العيب الوحيد لهذا الحل هو وجود العديد من عناوين URL النسبية (لا يوجد عنوان URL أساسي، حيث أن قيمة DISCOURSE_CDN_URL فارغة) في مصدر الصفحة، مما يجعله يبدو وكأنه ليس موقعًا على مستوى الإنتاج.
متابعة لأسئلتي، وجدت منشورًا مشابهًا لما أسأل عنه في هذا المنشور CloudFront not caching static files - #4 by Falco
أقدر إجابة @Falco، في إعداد CDN للموقع بالكامل هذا، هل يمكنني تعيين DISCOURSE_CDN_URL بنفس قيمة DISCOURSE_HOSTNAME؟ حيث أفترض أن إعداد CDN للموقع بالكامل يعني أن CDN تسرع عنوان URL الخاص باسم المضيف مما يجعل DISCOURSE_CDN_URL بنفس قيمة DISCOURSE_HOSTNAME. ولكن لا توجد وثائق لائقة حول هذا في meta.
مرحباً، هل يوجد قالب للأرنب؟
لا تحتاج إلى قالب لذلك، فقط قم بتكوين bunny للسحب من موقع discourse الخاص بك وقم بتعيين DISCOURSE_CDN_URL إلى نقطة نهاية cdn التي يوفرها bunny في app.yml
أحاول استخدام “تسريع شبكة توصيل المحتوى” (CDN acceleration) مع عنوان IP الخاص بخادم VPS الخاص بي مع Bunny DNS. إنه يعمل، ولكن جميع المستخدمين لديهم نفس عنوان IP.
لقد وجدت الإعداد للتو، ويسمى “X-Real-Ip”.