إنه أفضل من DigitalOcean وما شابه، لذا نعم، إنه شيء جيد.
كانت جيدة، لكني أبرزت أيضًا القيود، كانت المواقع ذات حركة مرور ونشاط منخفضين حقًا، إذا كنت تتوقع نشاطًا كبيرًا على هذه المواقع، فأنت بحاجة إلى المزيد من الموارد، ويزداد استخدام موارد ديسكورس (Discourse) كلما زاد النشاط الذي تتلقاه.
هذا يعتمد حقًا على ما إذا كانت لديك حاجة لعزل بعض المواقع عن الأخرى أم لا. عادةً ما تكون استضافة ديسكورس (Discourse) التجارية مجرد مجموعات كبيرة متعددة المواقع مع بعض الإضافات الخاصة للتعامل مع نظام الفوترة الخاص بهم وما إلى ذلك.
حسنًا، ما لم يكن لديك إعداد متقدم مطبق، ستشترك جميع المواقع في بيانات اعتماد موقع الرئيس. أي أنه بدون إعداد متقدم مطبق، إذا تم تكوين موقع الرئيس ليكون noreply@example.com كبريده الإلكتروني لعدم الرد. سيتم استخدامه من قبل جميع مواقع الأبناء أيضًا. ستحتاج إلى بعض الإعدادات الإضافية إذا كنت تريد رسائل بريد إلكتروني فريدة لكل موقع.
ملف app.yml واحد للمواقع المتعددة ممكن ولكني أوصي بالانتقال إلى تثبيت حاويتين (ويب وبيانات منفصلة) للمواقع المتعددة.
سيتعين عليك المثابرة خلال بعض التحديات، وتغيير المسارات في ملفات yml ثم تشغيلها. في الأساس، كما لو كان لـ /var/discourse-a إعداداته الخاصة و/var/discourse-b إعداداته الخاصة.
للتنويه، هذه مفاهيم تقنية معقدة للغاية، وأنت بحاجة حقًا إلى بعض الخبرة في Discourse وآلياته الداخلية لتتمكن من استضافة مواقع متعددة. إذا كنت تشعر بالتوتر حيال ذلك، فربما تفكر في استضافة مُدارة لـ Discourse أو اطلب من شخص إعداده لك بشكل احترافي. سيقلل هذا بشكل كبير من صداعك بمرور الوقت. فكر في النشر في Marketplace إذا كانت لديك ميزانية.
نعم، ولكن لهذا السبب كنت أقول إنه بمرور الوقت يمكنني دائمًا الترقية إلى خطة أعلى بمزيد من الموارد. لم تكن خطتي أبدًا البقاء على تلك… الخطة… لفترة طويلة. أنا فقط أحاول تجنب التكاليف غير الضرورية عند اختبار المياه، كما تعلم؟
هل يمكنك ذكر بعض الأسباب التي قد تجعلني أرغب في فصلها، بخلاف موارد الخادم؟ في الوقت الحالي، لا أرى سببًا وجيهًا لوجودها في خوادم منفصلة، لكني دائمًا على استعداد لتعلم بعض وجهات النظر المختلفة حول الأشياء التي لا أعرفها بعد.
هذه نقطة مثيرة للاهتمام للغاية، لم أكن أعرفها. لذا يبدو أنه شيء تم القيام به وهو يعمل. من الجيد معرفة ذلك.
ماذا تقصد بالموقع الأصل؟ ألن يكون كل تثبيت مستقلاً؟ أي واحد سيتم اعتباره الأصل؟
أنا مرتبك بعض الشيء، لأنه عندما ألقي نظرة على ملف app.yaml، هناك جزء مخصص لبريد إلكتروني و بيانات اعتماد Brevo. لقد قلت أنه يمكنني المضي قدمًا في مسار وجود ملفات app.yaml فردية لكل مجتمع. لذا، ألن يعني ذلك أن كل مجتمع سيكون لديه بيانات اعتماد Brevo الخاصة به، بما في ذلك البريد الإلكتروني للإشعارات؟
الأشياء التي ستمنعني من النسخ الاحتياطي بشكل صحيح، أو عدم إرسال رسائل البريد الإلكتروني للإشعارات بشكل صحيح، وأشياء من هذا القبيل. مرة أخرى، كوني غير خبير، وما زلت جديدًا على Discourse، هناك أشياء قد يراها الآخرون على أنها مشكلة، لكني لا أراها بعد.
نعم، هذا ما كنت أفكر فيه. الشيء الوحيد المشترك سيكون الخادم نفسه. كل شيء آخر سيعمل كتثبيت منفصل، ومن هنا جاء السؤال حول البريد الإلكتروني، أعلاه.
أعتقد أن الخطوات الأكثر تحديًا بالنسبة لي قد تم اتخاذها بالفعل، وهي التعمق في تثبيت Discourse قبل بضعة أشهر. لم تكن لدي أي معرفة به. لم أكن أعرف حتى ما يعنيه “docker”. في هذه المرحلة، لدي منظور أوضح بكثير، بينما ما زلت أعتبر نفسي “مستخدم Discourse أساسي” عندما يتعلق الأمر بالاستضافة الذاتية. وبمساعدة هذا المجتمع و ChatGPT/Claude، تمكنت من تعلم المزيد وتدوين ملاحظات حول كيفية عمل الأشياء وتثبيتها. أنا بخير مع التحديات، ولنكن صادقين: هذا مجرد تثبيت للبرنامج. ليس الأمر وكأنني أبني قنبلة نووية إذا ساء شيء ما، احذف كل شيء، عد إلى تثبيت واحد لكل خادم. كل شيء على ما يرام
كما ذكرت، لدي مجتمعي الخاص مثبت بالفعل، لذلك أعتقد أن الجزء الأصعب قد انتهى. أنا جيد في اتباع التعليمات وطرح الأسئلة، لذلك بينما أجرب الأشياء، يمكنني دائمًا التوقف وإجراء بعض الأبحاث، وتدوين الملاحظات، وما إلى ذلك.
هدفي الآن يتعلق أكثر بفهم آليات ذلك، والمزايا والعيوب، وما هو ممكن وما هو غير ممكن، حتى أتمكن من اتخاذ قرارات جيدة لن أندم عليها لاحقًا وتتطلب مني قضاء الكثير من الوقت في إصلاح الأشياء، كما تعلم؟
لذا، كل هذه المعلومات التي تشاركونها اليوم قيمة للغاية، لأنها تعطيني فكرة جيدة عما يجب التفكير فيه. خاصة عندما ذكرت أن الاستضافة المُدارة التي يقدمها فريق Discourse هي متعددة المواقع. هذا جعلني أرى حقًا أن هذا ممكن. ربما يتطلب بضع خطوات إضافية، ولكن كل شيء يمكن القيام به.
سيتعين عليك أولاً أن تقرر ما إذا كنت تريد موقعًا واحدًا متعدد المواقع (multisite) أو خادمًا واحدًا يستضيف مواقع مستقلة متعددة. سأتوقف عن الإجابة على أي شيء سألت عنه أعلاه قبل أن تقرر بين أحدهما والآخر. هناك الكثير مما يجب فهمه، فمجرد تثبيت ديسكورس (Discourse) على جهاز افتراضي (VM) لا يجعلك مؤهلاً تلقائيًا لمتاعب تعدد المواقع، على سبيل المثال، استغرقت مني 3 سنوات لإتقان تجربة تثبيت تعدد المواقع لنفسي. صحيح أن الوثائق لم تكن واضحة جدًا بشأن العديد من الأشياء واضطررت إلى اكتشاف (FTFO) الكثير من الأشياء للحصول عليها بشكل صحيح. وأنا أستخدم ديسكورس (Discourse) منذ 2016-2017 (ما يقرب من 9-10 سنوات في هذه المرحلة)
لذا، يرجى التراجع خطوة، وإعادة التفكير فيما تحاول تحقيقه، وبعد ذلك يمكننا التركيز على تحقيق ذلك.
مرة أخرى، ضع في اعتبارك أن تثبيت ديسكورس (Discourse) ليس العقبة الأكبر، فلا يزال هناك الكثير لتعلمه، وحتى بعد 9 سنوات من استخدام ونشر ديسكورس (Discourse)، ما زلت أعتبر نفسي أتعلم أشياء جديدة كل يوم.
كان هذا هو هدفي دائمًا. لا أرى أي ميزة، لما أقوم ببنائه، في وجود موقع واحد متعدد المواقع. هدفي هو فقط توفير التكاليف باستخدام خادم واحد بتثبيتات مستقلة.
وأنا أفهم ما تقصده بشأن تعقيد الأمور. لهذا السبب كنت أقول إنه على الرغم من أنني تمكنت من تثبيته وأصبحت الآن قادرًا على فهم بعض المفاهيم، إلا أنني أعتبر نفسي مستخدمًا أساسيًا عندما يتعلق الأمر بالتثبيت.
بعد صنع الموسيقى لما يقرب من 35 عامًا، ما زلت أتعلم أشياء جديدة كل يوم، لذا فهذا جيد. أنا جيد في التعلم كل يوم، ولا أتوقع ألا أفعل ذلك لهذا السبب أنا هنا في هذا المجتمع. لتعلم أشياء جديدة معكم يا رفاق.
إذا كنت ترغب فقط في الحصول على مواقع Discourse متعددة على نفس الخادم، دون أن تتشارك في الكود أو الحاوية، فإليك ما يمكنك تجربته:
اقرأ ملف app.yml بعناية وافهم قسم عمليات التثبيت (mounts). ستحتاج إلى عمليات تثبيت مختلفة ومتوقعة لكل موقع، والحد الأدنى هو أن تقوم بتعديل هذه الأدلة يدويًا.
المرة الوحيدة التي قمت فيها بذلك (وأعتقد أنني فعلتها بأكثر الطرق غير المريحة) هي أنني استنسخت كود discourse في دليلين مختلفين، وهو ما قد لا يكون ضروريًا، ولكني لم أجرب ذلك لذا لست متأكدًا.
في كل دليل، قمت بتشغيل ./discourse-setup مع بعض العلامات لتخطي التحقق من الاتصال وإعادة البناء. أعطاني ذلك ملفات app.yml أساسية. كانت الخطوة التالية هي تعديل كلا الملفين يدويًا، قمت بتغيير عمليات التثبيت، وعلقّت القسم الذي يعرض المنافذ وأضفت قالب web.socketed للسماح لخادم Nginx الخارجي الخاص بي بالتعامل مع SSL وإعادة التوجيهات الداخلية.
بعد ذلك، كان الأمر بسيطًا مثل تشغيل ./launcher rebuild app في كل دليل.
بصراحة، لم أكن من أشد المعجبين بهذا الإعداد، لذا استسلمت بعد بضعة أشهر من التجريب. لكنه يوضح أن ما تحاول القيام به ممكن بالفعل، فقط عليك أن تكتشف بعض الأمور.
قد ترغب أيضًا في خفض عدد العمال وما إلى ذلك للسماح لجميع المواقع بالحصول على فرصة عادلة لاستخدام الموارد، ولكن هذه تجربة فكرية عندما تضع الأساس الأولي.
إذا كان الأمر كذلك، فهل هذا هو المكان الذي أنشئ فيه مسارات مختلفة مثل
var/discourse/shared/website1
var/discourse/shared/website2
إلخ؟
إذًا، هل قمت بتنفيذ تثبيت عادي في أحد المسارات، على سبيل المثال:
var/discourse/shared/website1
ثم نسخت تلك الملفات إلى
var/discourse/shared/website2
؟
إذا كان الأمر كذلك، فلماذا تقوم بتشغيل ./discourse-setup؟ ألن يؤدي ذلك إلى الكتابة فوق الملفات؟
ألن يكون من الأفضل ببساطة إجراء عمليات تثبيت عادية في كلا المسارين؟ مثل تثبيتات منفصلة بالكامل؟ بالنسبة لشخص مثلي، خاصة عندما تذكر “الأعلام” وكل تلك الأشياء، فهذه المزيد من الأشياء التي سأضطر للقلق بشأنها، وربما يكون التثبيت العادي أفضل، ثم تعديل ملفات app.yaml يدوياً في كل مسار؟
تعديل: لا تهتم. لقد أجريت بعض الأبحاث وأفهم ما تقصده بـ “النسخ” (clone) في هذا السياق. لقد نسخت ملفات المستودع (repository). اعتقدت أنك تقول إنك قمت بتثبيت كل شيء في “مسار” واحد ثم نسخت تلك الملفات إلى “مسار” آخر.
هل لديك بالفعل نسخة من Discourse قيد التشغيل؟ لقد كنت في هذا المنتدى لفترة. هل تحاول تشغيل نسخة ثانية على خادم لديه نسخة واحدة قيد التشغيل بالفعل؟
أفضل طريقة للتعلم هي المحاولة. قم بإعداد خادم افتراضي خاص (VPS) رخيص وجرب. إذا لم تكن تدير نسخة بالفعل، فما عليك سوى الحصول على تثبيت عادي مستضاف ذاتيًا ومدعوم وتعلم كيفية التنقل فيه. لن يكون لديك زوار حقيقيون ولن يكون هناك سبب لحفظ أي شيء. يمكنك ببساطة حذف التثبيت والمحاولة مرارًا وتكرارًا حتى تتقن الأمر. إذا قمت بإعداد نسختين أو حتى ثلاث نسخ تعمل جميعها على خادم افتراضي خاص واحد وكلاهما يحصل على عدد (تقريباً) صفر من الزيارات، أراهن أن أرخص خادم افتراضي خاص متاح سيشغلها على الأرجح.
إذا نجحت في تشغيلها، انشر برنامجًا تعليميًا لكي نتعلم منه جميعًا!
نظرًا لأن هذا التثبيت لا يزال جديدًا ولم يشترك فيه أي مستخدمين، فلا توجد مشكلات في ذلك. سأقوم بعمل نسخة احتياطية أولاً وأجرب كل شيء على هذا الخادم. لا يوجد خطر حقيقي بعد.
سأفعل ذلك بالتأكيد. آمل أن يساعد ذلك الآخرين.
@itsbhanusharma كنت أطرح بعض الأسئلة الإضافية على كل من ChatGPT و Claude، لأنني كنت أفكر في أنني أرغب في تغيير اسم مسار النسخة الحالية من “discourse” إلى اسم الموقع مثل “website-name” وقد أشار كلاهما إلى بعض النقاط الجيدة. أحدها هو أنه نظرًا لأن كل تثبيت يتطلب 2 جيجابايت من ذاكرة الوصول العشوائي (RAM)، إذا قمت بتثبيت 5 في المجموع، على سبيل المثال، سأحتاج إلى 10 جيجابايت، أليس كذلك؟
إذا كانت هذه هي الحالة، فمن المحتمل أن تكون هذه الخطة أفضل:
لدي حوادث متعددة لعملاء يسببون ضررًا أكثر من النفع لمواقع النقاش الخاصة بهم لأنهم اتبعوا نصيحة ChatGPT بشكل أعمى.
هذا أكثر تعقيدًا ونوع من الأشياء التي ليست واضحة مثل جمع 2+2. وهذا هو السبب الرئيسي وراء كون مسار التثبيت المتعدد (multisite route) فكرة أفضل.
مرة أخرى، أود أن أقول توقف، وخذ استراحة، وابتعد قليلاً وأعد التفكير في احتياجاتك. هناك موارد جيدة متاحة هنا في ميتا وروبوت الذكاء الاصطناعي الوحيد الذي أثق به للحصول على نصيحة حول Discourse هو https://ask.discourse.org
هذا متطرف بعض الشيء… لا أحد يتبع نصيحة ChatGPT بشكل أعمى (على الأقل أنا لا أفعل)، ولهذا السبب أجري هذه المحادثة معكم جميعًا هنا.
أنا أستخدم تلك الأدوات كأدوات. إنها تذكر أشياء تسمح لي برؤية وجهات نظر أخرى، ثم أبحث عبر الإنترنت، أو أطرح أسئلة هنا في المجتمع. على طول الطريق، تعرض لي أيضًا مفاهيم أخرى غير مرتبطة بشكل صارم بـ Discourse، وهو أمر جيد أيضًا. الأدوات جيدة فقط بقدر جودة الشخص الذي يستخدمها.
وقد أنجزت الكثير باستخدام نصائح من ChatGPT و Claude. لا يمكننا رفض كل ما يقولونه… بشكل أعمى
هل تمانع في مشاركة المزيد حول هذا؟ إذا كانت المعلومات التي يقدمها ChatGPT / Claude غير دقيقة، فربما يمكنك إرشادي، وكذلك الآخرين الذين قد يقرؤون هذا في المستقبل؟
ليس في حالتي، لعدة أسباب (وما لم أكن أخطئ في فهم شيء ما، فإليك هي):
أريد أن أكون قادرًا على إجراء تغييرات مخصصة، إذا لزم الأمر، على كل نسخة، دون التأثير على النسخ الأخرى. ليس أنني سأفعل ذلك، ولكن أريد أن أعرف أنني أستطيع ذلك إذا أردت.
في نظام المواقع المتعددة، إذا تعطل الموقع الرئيسي، فإنها جميعًا تتعطل، أليس كذلك؟
أنا فقط أحب أن تكون الأشياء مستقلة. إن فكرة أن 4-5 نسخ متصلة جميعها بشيء يمكن أن يفشل في مرحلة ما تزعجني.
مرة أخرى، ربما يكون منظوري لكيفية عمل نظام المواقع المتعددة خاطئًا، ولكن من فهمي، لا يبدو أنه مناسب لي.
في الوقت الحالي، احتياجاتي هي:
بناء جميع المجتمعات التي أحتاجها
إنفاق أقل قدر ممكن من المال، لأنني لا أعرف ما إذا كانت قرارات بناء تلك المجتمعات جيدة على المدى الطويل أم لا (لقد مررت بذلك، أكثر مما أود، بإنفاق الكثير من المال على “التجارب”).
لم أكن أعرف عن هذه الأداة، لذا شكرًا لك على مشاركتها. قمت بحفظها في الإشارات المرجعية.
يجب أن أقول، مع ذلك، أنه لا ينبغي علينا بشكل أعمى (آسف، كان علي أن أفعلها مرة أخرى هههه) تجاهل كل ما يقوله ChatGPT أو Claude، حتى لو كان روبوت الذكاء الاصطناعي الخاص بـ Discourse أكثر دراية، وهو ما أعتقد أنه كذلك مع وجود الكثير من المحتوى المتاح حول هذا الموضوع. أنا أستخدم ChatGPT و Claude أيضًا، لأنه في بعض الأحيان تكون بعض الأشياء غير مرتبطة فقط بـ Discourse وأنا دائمًا أحب أن أتعلم المزيد عن أشياء أخرى.
على أي حال، أقدر ملاحظاتك ووقتك. لقد ساعدتني كثيرًا بالفعل.
مما أفهمه من هذا هو أنك غارق في التفكير المفرط في إعدادك.
في الأساس، لا ينبغي لك السعي وراء الأفكار المجتمعية الرائعة الـ 1000 التي لديك كلها دفعة واحدة عن طريق تشغيل أكبر عدد ممكن من مثيلات ديسكورس (وبالتالي أي برنامج آخر).
بناء المجتمع عملية تكرارية ويتطلب تركيزًا، إذا قمت بتقسيم تركيزك بين أكثر من مجتمع واحد في كل مرة، فسيكون لديك ما هو أكثر مما يمكنك التعامل معه.
كانت اقتراحاتي مجرد مادة للتفكير، كما ذكرت سابقًا عندما أجريت هذه التجارب، كانت مجرد مجموعة من الأصدقاء يفعلون الأشياء لأننا نستطيع.
هناك سبب (أو سببان) لعدم شيوع هذه الممارسات؟ فهي تأتي مع عبء صيانة وإدارة كبير سيسبب الكثير من الصداع والليالي التي لا تنام في المستقبل، لقد تم تحذيرك.
نظرًا لأهدافك، سأنهي كلامي بهذه الملاحظة: ما تحاول تحقيقه ليس مستحيلاً، ولكن اليوم ليس اليوم لتحقيق كل ما هو ممكن. ركز على ما هو متاح لديك، وابنِ مجتمعك الأول، ويمكن للباقي أن يتبع عندما يحين الوقت.
أما بالنسبة للتعلم عن طريق التجريب، إذا كان خفض التكاليف هو هدفك الأساسي، فإن الموقع المتعدد هو الطريق، بكل التنازلات التي يقدمها.
أتفهم ما تقصده، وصدقني، لو كنت سأبني جميع المجتمعات التي أحتاجها لكل شيء أشارك فيه، فلن نتحدث عن 4-5، بل عن 15 مجتمعاً تقريباً.
لقد تمكنت من الوصول إلى 3 تبدو مهمة حقاً ويجب بناؤها الآن. في هذه المرحلة، يحتاج الثلاثة جميعاً إلى مساحتهم الخاصة لمنح المستخدمين مكاناً لمناقشة تجاربهم مع المنتجات والخدمات التي أمتلكها أو أقوم ببنائها.
كما قلت، التكوين متعدد المواقع (multisite) حيث يعتمدون جميعاً على بعضهم البعض، لا يبدو مناسباً لي، وبصراحة، فإن الصداع والليالي التي لا تنام التي ذكرتها، من المرجح أن توجد في تلك الحالة (على الأقل بالنسبة لي ووفقاً لخبرتي في مجالات أخرى كانت فيها الأشياء تعتمد على بعضها البعض)، في تكوين متعدد المواقع. لا أعرف… إنها إحدى تلك الحالات التي تقول فيها حدسي “لا تفعل ذلك” وأنا أثق به. ربما أكون مخطئاً وسيتم إثبات خطئي مع مرور الوقت، لكنني أثق بحدسي أولاً.
على أي حال، شكراً لك مرة أخرى على وقتك ومساعدتك. أقدر ذلك
هذا موضوع مناسب لي حيث أنني في خضم عملية تعديل إعداداتي لتوفير بعض الوقت والمال. لدي ثلاثة مواقع خاصة صغيرة تحصل جميعها على حركة مرور قليلة جداً ولكنها جميعها مهمة بالنسبة لي. أريد أيضاً أن أكون قادراً على إنشاء المزيد من المواقع لاختبار أفكار جديدة. لذا أعتقد أن تعدد المواقع (multisite) سيكون ذا أهمية بالنسبة لي.
ومع ذلك، لقد نقلت للتو أحد مواقعي من DigitalOcean إلى Hetzner، وتفاجأت بمدخرات التكلفة. إنها تكلف 3.49 دولار فقط شهرياً مقابل أصغر عرض لديهم وهو cx23، والذي يبدو مثالياً لموقع واحد صغير. كنت أدفع 15.60 دولاراً في DigitalOcean لإعداد مماثل.
بعد قراءة هذا والمواضيع الأخرى ذات الصلة، فإن نقطة الخلاف الرئيسية لدي مع تعدد المواقع هي أنني أريد استخدام البريد الإلكتروني للتسليم المباشر لجميع مواقعي، باستخدام اسم نطاق الموقع كاسم نطاق البريد الإلكتروني لكي يتم التعرف عليه بسهولة والثقة به من قبل أعضاء الموقع. لا تبدو التعليمات الخاصة بإعداد ذلك واضحة جداً.
لذا في الوقت الحالي، أستنتج أنه قد يكون من الأفضل لي التمسك بالمواقع المستقلة ونقلها جميعاً إلى Hetzner. سأوفر المال ولكن ليس الكثير من الوقت نظراً لكمية الوقت الضائع في إعداد المواقع المستقلة.
يمكنك فعل ذلك ولكن فقط إذا كانت جميعها تستخدم نفس بيانات اعتماد SMTP.
نظرًا لأن خادم Hetzner الجديد الخاص بك أرخص بكثير، فستظل تحقق مكاسب مع ثلاثة مواقع بدلاً من موقع واحد بالسعر القديم.
لا أوصي بتعدد المواقع (multisite) بذاكرة وصول عشوائي (RAM) تبلغ 1 جيجابايت فقط، وستكون هناك المزيد من المتاعب في إعداده، على الرغم من أن إعداد متغير البيئة (environment variable) الخاص بأسماء المضيفين الجديدة يحل إحدى أكبر المشكلات.
يحتوي cx23 على 4 جيجابايت من ذاكرة الوصول العشوائي. سأقوم بنقل موقعي الآخرين إلى خوادم cx23 المنفصلة الخاصة بهما، لذا سنرى كيف ستسير الأمور، ولكن شعوري هو أنها ستكون على ما يرام.
أنا مرتبك بسبب هذا لأن مستقبل البريد (mail-receiver) يتعلق فقط باستلام البريد الإلكتروني ولا توجد بيانات اعتماد SMTP.
هل تتحدث عن البريد الإلكتروني الوارد أم الصادر؟ بالنسبة للبريد الإلكتروني الصادر، أليس لكل موقع بيانات اعتماد SMTP خاصة به مهيأة في ملف app.yml؟
لا. مستقبِل البريد منفصل. إذا كنت تستخدم مواقع متعددة، فهناك ملف YML واحد فقط، وهناك يتم تعيين بيانات اعتماد إرسال SMTP. إذا كنت تستخدم مستقبِل البريد، فلديك مشكلة مختلفة، حيث تحتاج إلى مستقبِل بريد لكل موقع (على الأقل، هذا هو الحل الوحيد الذي وجدته).
إذا ساء شيء ما، احذف كل شيء، عد إلى تثبيت واحد لكل خادم. كل شيء على ما يرام 
