مرحباً ![]()
أنا أتبع هذا الدليل على Github وأنت توصي بـ Namecheap هناك.
لقد تابعت ذلك، وتقول إنه يجب علي التحقق من نطاق فرعي.
مشكلتان:
في أي مكان على Namecheap لا يوجد خيار يسمح لي بفعل ذلك.
في أي مكان في وثائقك لم يُذكر كيف يمكنني فعل ذلك.
مرحباً ![]()
أنا أتبع هذا الدليل على Github وأنت توصي بـ Namecheap هناك.
لقد تابعت ذلك، وتقول إنه يجب علي التحقق من نطاق فرعي.
مشكلتان:
في أي مكان على Namecheap لا يوجد خيار يسمح لي بفعل ذلك.
في أي مكان في وثائقك لم يُذكر كيف يمكنني فعل ذلك.
ستقوم بإنشاء سجل A لأي نطاق فرعي تريده كما هو موضح في https://www.namecheap.com/support/knowledgebase/article.aspx/319/2237/how-can-i-set-up-an-a-address-record-for-my-domain/.
شكراً جزيلاً!
شخصياً، هذا لا يساعد حقاً، لأنه لا توجد تعليمات واضحة ومخصصة حول كيفية إعداد نطاق فرعي.
أيضاً، الدليل لا يقول شيئاً على الإطلاق عن ذلك.
هل نحن متأكدون أن هذا يساعد الناس كما هو؟
موجود في تعليمات التثبيت القياسية على GitHub.
“يجب أن تكون عناصر تحكم DNS الخاصة بك قابلة للوصول من المكان الذي اشتريت منه اسم النطاق الخاص بك. هذا هو المكان الذي ستنشئ فيه سجل A record لنظام أسماء النطاقات لاسم المضيف discourse.example.com بمجرد معرفة عنوان IP الخاص بخادم السحابة حيث تقوم بتثبيت Discourse، بالإضافة إلى إدخال سجلات SPF و DKIM الخاصة بالبريد الإلكتروني الخاص بك.”
ذلك لأنه لا يوجد شيء لذلك. إنها مجرد سجل DNS من نوع A يشير إلى خادم.
على بعض الأنظمة، يبدو أن “إعداد نطاق فرعي” شيء كبير لأنه يتطلب نظامًا يقوم بعدة أشياء، بما في ذلك تثبيت شيء يجيب على طلبات https (ستقوم بتثبيت Discourse) الذي يعمل في مكان ما (ستنشئ VM) وتوجيه سجل DNS إليه (الجزء الذي يبدو أنك تجد صعوبة في فهمه؟).
كنت مخطئًا بشأن @، أعتذر، العمود هو “المضيف”.
إليك بعض الأمثلة:
حيث القيمة هي عنوان IP المطلوب.
إذًا:
demo.example.comdev.example.comsnow.example.comهذا كل شيء حرفيًا!
(على الرغم من أنك ستحتاج أيضًا إلى طلب شهادة باستخدام شيء مثل Let’s Encrypt من الخادم ما لم يتم ذلك تلقائيًا كما هو الحال مع Discourse)
لشخص لم يتعامل مع ذلك من قبل، فإن الأمر ليس شيئًا بسيطًا.
هذا أقرب بالفعل إلى حل فعلي. لا يزال الناس لا يعرفون كيف يحصلون على عنوان IP الخاص بهم.
إذا كان من المفترض أن يقتصر هذا على الأشخاص الذين هم مبرمجو الويب بالفعل، فإذن الوثائق الحالية تناسب ذلك على الأرجح.
إذا كنت تنوي توفير الفرص التي تأتي مع Discourse للجميع بشكل متساوٍ، فهناك الكثير من العمل لم يكمل بعد.
مطور الويب الخاص بي واجه العديد من الصراعات في إعداد مضيف SMTP، كمثال - لم أكن لأتمكن من تنفيذ ذلك أبدًا.
إنه نفس عنوان IP الخاص بالخادم الافتراضي الخاص (VPS) الذي تسجل الدخول إليه لتثبيت Discourse.
هذه هي جميع المعلومات التي من المهم توثيقها للمستخدم الجديد. أنا مستعد لبذل هذا الجهد، إذا كنت مهتمًا بدمجه.
ربما بتفاصيل أكثر. ومع ذلك، فإن مزود VPs الخاص بك لديه عنوان IP في لوحة التحكم مع مواصفات الخادم.
ستعتمد سهولة هذا على SMTP الذي تختاره للاستخدام. على سبيل المثال، Brevo.com، ما عليك سوى تسجيل اسم مستخدم وكلمة مرور واستخدام الخطط المجانية أو المدفوعة.
ثم ما عليك سوى إدخال اسم المستخدم وكلمة المرور في إعدادات discourse وعنوان SMTP
العنوان أعلاه قياسي في discourse. قد يوفر مزود SMTP أيضًا تعليمات لإنشاء سجل DNS إذا فهمت بشكل صحيح لتمكين dkim للمساعدة في ضمان تسليم البريد.
ثم لديك البعض مثل Lark وهو إعداد أكثر تعقيدًا مما نشرته أعلاه.
لهذا السبب يوجد Discourse Meta للمساعدة في تقديم دعم رسمي ودعم مجتمعي. إذا كان لدى المرء ميزانية، فهناك العديد من الأشخاص الذين سيقومون بالإعداد الأولي وبعضهم مثل @pfaffman للمستخدمين المستضافين ذاتيًا لديه لوحة تحكم دعم مقابل رسوم سنوية بسيطة تتضمن أيضًا دعمه. تمنح لوحة التحكم خيارات لتثبيت الإضافات وإجراء بعض الصيانة عبر سطر الأوامر للمستخدمين الأقل خبرة تقنية.
فقط للتوضيح، أنا متعاطف مع وجهة نظرك ويجب أن أقول. في هذا العصر، يعتبر واجهة المستخدم الرسومية (GUI UX) أكثر توحيدًا للمستخدم العادي اليومي.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.