كيفية تشغيل discourse في دليل فرعي لنطاق خارجي؟

نحن ننتقل من موقعنا على ووردبريس إلى منصة تجارة إلكترونية مستضافة على السحابة، والتي ستستخدم نطاقنا الأساسي نظرًا لترتيبنا العالي في تحسين محركات البحث.

أود نقل منشوراتنا إلى discourse، ولكن تشغيلها تحت نفس النطاق. هل هذا ممكن؟

وللتوضيح، فإن http://ultraluz.com.br/ سيعمل على خادم خارجي لا أستطيع التحكم فيه أو الوصول إليه، لذا أعتقد أنني لا أستطيع استخدام حيل nginx أو ما شابه. أملك فقط الوصول إلى الخادم الذي سيشغل discourse.

هدفي هو نقل منشورات مثل هذا الرابط http://ultraluz.com.br/iluminacao-para-esportes-como-deixar-as-instalacoes-esportivas-dignas-de-um-atleta-profissional/ إلى discourse مع الحفاظ على نفس المسار، أو على الأقل استخدام domain/blog/same-url، بينما يتم توجيه نطاقنا الأساسي واستضافته على منصة شبيهة بـ Wix.

قد يكون من الممكن وضع Cloudflare أمام الموقعين مع قاعدة لتوجيه حركة المرور إلى Discourse للمجلد الفرعي. أنا لست على علم بأن أي شخص فعل ذلك. ربما ستحتاج إلى توظيف شخص ما أو حل الأمر بنفسك. فقط اتبع الموضوع هنا حول تثبيتات المجلدات الفرعية وما لديه Cloudflare حول نفس الأمر.

كنت أعتقد أن الاعتقاد بأن المجلد الفرعي أفضل لتحسين محركات البحث قد تلاشى. توصيتي هي ببساطة استخدام نطاق فرعي، ولكن إذا كان لديك ميزانية، فاتصل بي أو انشر في Marketplace.

يمكنك نظريًا تحقيق جزء المجلد الفرعي في Cloudflare باستخدام قاعدة صفحة Enterprise أو ربما عبر Workers، لكنني أشك بشدة في قدرتنا على تقديم أي مساعدة في أي من الحالتين.

من الصعب دعم Cloudflare بأي شكل يتجاوز DNS.

ونعم، دحضت جوجل نفسها تمامًا ادعاءات تحسين محركات البحث (SEO) غير الموثوقة حول حشر كل شيء تحت نطاق واحد.

الأمان أفضل من الندم في تحسين محركات البحث (SEO). لا أرى كيف يمكن أن يعزز نطاق فرعي مثل blog.domain تحسين محركات البحث لنطاقك الرئيسي، لذا لا فائدة من استخدام نطاق فرعي للمدونة على الإطلاق.

لقد كنت أفكر في اتباع هذا الدليل. أي من الخيارات التالية يجب أن أستخدمه؟

    assetsPathnames: ["/public/", "/assets/"]

تثبيتات المجلدات الفرعية أكثر تعقيدًا بكثير وهشة للغاية.

الهدف هو أنه لا توجد أي فائدة في التشغيل تحت نفس اسم النطاق الكامل (FQDN)، بينما تزداد المخاطر والتكاليف بشكل كبير.

هذا ما تؤمن به. لكن لا توجد أي أدلة على أن النطاق الفرعي يساعد في تعزيز النطاق الأساسي على الإطلاق.

بل إن كلاودفلير نفسها توصي بتشغيل كل شيء ضمن نفس النطاق.

إذن، لماذا، أرجوك قل لي، توجد مجتمعهم النقاشي في نطاق فرعي؟

لأن أي شيء يحتوي على Cloudflare في النطاق سيحقق ترتيبًا جيدًا. كما أن منتداهم ضخم.

إذا كان هذا ما تؤمن به، فامضِ في طريقك. ليس هناك شيء لك هنا. اذهب إلى مكان آخر، إلى مكان يؤمن فيه الناس بنفس المعتقدات التي تؤمن بها.

كان بإمكاني إضافة المزيد من الروابط المدعومة بالبيانات لو لم أكن مقيدًا ب رابطين فقط. وباستثناء Cloudflare، وهي شركة ضخمة ولا تحتاج إلى التركيز على تحسين محركات البحث، فإن جميع المواقع في الصفحة الأولى لنتائج هذا البحث تستخدم المجلدات الفرعية.

لن يكون من الصعب العثور على أماكن أخرى يعتقد فيها الناس نفس الشيء، حيث يبدو أن هذا هو الإجماع في مجتمع تحسين محركات البحث.

لكن بالتأكيد، إذا كانت لديك أي دليل على أن النطاقات الفرعية تساعد في تحسين ترتيب النطاق الجذري، فيرجى إضاءة الإنترنت بذلك :slight_smile:

مباشر من مات كتس. خبراء تحسين محركات البحث (SEO) الخاصون يبيعونك أكاذيب.

على مر السنين، كان بعض الأسوأ والأقل كفاءة الذين رأيتهم على الإطلاق في فريق هم “خبراء تحسين محركات البحث”. إنهم جميعًا عار ومهانة لهذه الصناعة.

صحيح! من الأفضل بكثير فعل شيء يتفق معظم الناس على أنه لن يساعد في ترتيب المواقع، لكنه قد يؤدي على الأرجح إلى توقف موقعك بشكل غير متوقع دون وجود وسيلة واضحة لإصلاحه.

هل جرب أحدكم القيام بذلك مع Cloudflare؟

كما أوضحنا بالفعل في موضوعك الآخر، لا يمكن دعم ما تطلب القيام به هنا.

ستحتاج إما إلى خطة Enterprise مع Cloudflare، أو إلى إنشاء عملاء مخصصين. في كلتا الحالتين، يجب أن تتواصل مع Cloudflare.

كما هو مذكور، الإجابة التي قدمتها سابقًا هي كل ما ستحصل عليه هنا.

ما لم أوضحه بوضوح كافٍ هو أن هذا أمر مستحيل.

كمعيار مرجعي، سأفرض عليك رسومًا تقدر بحوالي 1000 دولار ولن أضمن أن يعمل الأمر لأكثر من أسبوع بعد إعداده. (أو ربما أفرض عليك 500 دولار دون ضمان قدرتي على حل المشكلة من الأساس.

وستحتاج إلى خطة Cloudflare Enterprise.

إذا كنت مهتمًا، انشر في قناة Marketplace واذكر الميزانية المتاحة، وأيضًا أنك مستعد لدفع تكاليف خطة Cloudflare Enterprise، مع إدراك أن الأمر على الأرجح مستحيل.

أعتقد أنني أنهيت 80% من تنفيذ هذا. قمت بتثبيت discourse على نطاق فرعي كـ “تثبيت” عادي.

ثم أنشأت عامل Cloudflare يقوم بتمرير /blog إلى نطاقك الفرعي. إنه يعمل، لكن Chrome يرفض تحميل بعض العناصر بسبب سياسة CSP.

هل لدى أي شخص أي أفكار للتغلب على هذا؟ سأشارك كود العامل الخاص بي عندما يكتمل بنسبة 100%.

يمكنك زيارة https://ultraluz.com.br/blog للتحقق مما يحدث.

فكرتي هي أنه بعد إصلاح هذا، سأستخدم ملف robots.txt لمنع Google من فهرسة نطاقك الفرعي، بحيث يرى ويفهرس فقط /blog، بينما لا يزال بإمكانني الوصول إلى النطاق الفرعي بسهولة إذا لزم الأمر.

لن يعمل هذا أبدًا بشكل جيد مع “تثبيت عادي”، يجب عليك حقًا اتباع إجراءات التثبيت في مجلد فرعي. سيحل هذا مشكلات CSP والعديد من المشكلات الأخرى. وبالإضافة إلى ذلك، أعتقد أنك تقترب من الانتهاء.

ما الذي يجب أن أقوم بتعيينه لـ DISCOURSE_HOSTNAME عند استخدام DISCOURSE_RELATIVE_URL_ROOT؟ هل الجذر النسبي سيكون blog بالنسبة لي؟

كيف يؤثر هذا على الأشياء المتعلقة بـ SSL؟ هذا هو قسم env في ملف yml الخاص بي:

env:
  LANG: en_US.UTF-8
  DISCOURSE_RELATIVE_URL_ROOT: /forum

  VIRTUAL_HOST: forum.ultraluz.com.br
  VIRTUAL_PORT: 80
  LETSENCRYPT_HOST: forum.ultraluz.com.br
  LETSENCRYPT_EMAIL: redacted@email.com

  DISCOURSE_HOSTNAME: forum.ultraluz.com.br
  DISCOURSE_DEVELOPER_EMAILS: 'redacted@email.com'

  DISCOURSE_SMTP_ADDRESS: smtp.sendgrid.net
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: apikey
  DISCOURSE_SMTP_PASSWORD: "password"
  DISCOURSE_SMTP_ENABLE_START_TLS: true
  SSL_POLICY: Mozilla-Modern  

أشياء letsencrypt والعميل الافتراضي مخصصة لـ nginx docker الخاص بي (jwilder/nginx-proxy) الذي يتولى عملية التوجيه وإنشاء SSL بناءً على تلك المتغيرات…

كان لدي أيضًا هذا، لكنني أعتقد أنه سيتم استبداله بالكامل بالكود الموجود هناك؟

run:
  - replace:
      filename: /etc/nginx/conf.d/discourse.conf
      from: "types {"
      to: |
        set_real_ip_from 172.18.0.0/24;
        real_ip_header X-Forwarded-For;
        real_ip_recursive on;
        types {

نعم، /blog بما في ذلك الشرطة المائلة.

لا، فقط ultraluz.com.br.

أعتقد أنه يجب عليك ترك جزء LetsEncrypt كما هو.

لم ينجح الأمر بهذه الطريقة. أعتقد أن السبب هو أن العامل (worker) يحتاج إلى نطاق لجلب البيانات، وبما أن النطاق الجذر موجود على عنوان IP مختلف.

أنا في الأساس أخبر العامل: “عندما يزور شخص ما /blog، قم بجلب هذا من rootdomain/blog”، وهذا بالطبع يعرض فقط صفحة خطأ 404 الخاصة بـ WordPress الحالية.

أعتقد أنه بسبب مسألة النطاق الواحد مع عناوين IP/خوادم متعددة، فإن استخدام نطاق فرعي ضروري لتحميل أصول Discourse. لكن الوقت متأخر الآن ويحتاج الأمر إلى النوم.

لكنني أعتقد أن أسهل طريقة لتحقيق ذلك هي ببساطة إصلاح أخطاء سياسة محتوى الأمان (CSP) باستخدام تثبيت النطاق الفرعي المعتاد.