Ultimate Multisite 101
Ultimate Multisite هو إضافة WordPress Multisite تمكنك من تقديم WaaS أو مواقع الويب كخدمة للعملاء. قبل أن نغوص في كيفية مساعدة Ultimate Multisite لأعمالك وعملائك، هناك بعض المعرفة الأساسية التي نحتاج إلى اكتسابها.
WordPress Multisite
معظمنا على دراية بتثبيت WordPress القياسي. يمكنك إنشاؤه إما عبر لوحة تحكم مزود الاستضافة الخاص بك أو، للمتحمسين، إعداد خادم ويب وقاعدة بيانات جديدة، تحميل ملفات النواة والبدء في عملية التثبيت.
يعمل هذا على ملايين مواقع WordPress في جميع أنحاء العالم، لكن من منظور وكالة أو مزود استضافة دعونا نناقش الأحجام لحظة.
بينما يُعد إنشاء موقع WordPress واحد أو حتى مائة عبر لوحة تحكم آلية أمرًا متزامنًا، فإن المشكلات تظهر بسرعة عندما يتعلق الأمر بإدارة هذه المواقع. بدون إدارة، أنت هدف رئيسي للبرمجيات الخبيثة. إدارة المواقع تتطلب جهدًا وموارد، وعلى الرغم من وجود أدوات وإضافات خارجية تساعد في تبسيط إدارة WordPress، فإن حقيقة أن العملاء يحتفظون بالوصول الإداري يعني أن هذه الجهود يمكن أن تُهزم بسهولة.
في جوهره، يوفر WordPress ميزة تُسمى ببساطة "Multisite" التي تعود أصولها إلى 2010 عند إطلاق WordPress 3.0. منذ ذلك الحين، حصلت على عدد من التعديلات التي تهدف إلى تقديم ميزات جديدة وتكريس الأمان.
بشكل أساسي، يمكن التفكير في WordPress Multisite على النحو التالي: جامعة تحتفظ بتثبيت واحد من WordPress لكن كل كلية تحتفظ بموقع WordPress خاص بها.
لفهم هذا البيان، دعونا نلقي نظرة على بعض المصطلحات الأساسية الموجودة ليس فقط في وثائق Ultimate Multisite ولكن أيضًا في مجتمع WordPress.
الشبكة
من منظور WordPress، تعد شبكة Multisite مكانًا يمكن فيه إدارة عدد من المواقع الفرعية من لوحة تحكم واحدة. على الرغم من أن إنشاء شبكة Multisite يختلف بين مزودي الاستضافة، فإن النتيجة النهائية عادةً ما تكون بعض التعليمات الإضافية في ملف wp-config.php لإعلام WordPress أنه يعمل في هذا الوضع المحدد.
هناك عدد من الاختلافات المميزة بين شبكة Multisite وتثبيت WordPress مستقل نناقشها بإيجاز.
نطاق فرعي مقابل دليل فرعي
أحد أهم القرارات التي ستحتاج إلى اتخاذها هو ما إذا كان التثبيت Multisite سيعمل مع دلائل فرعية أو نطاقات فرعية. يعمل Ultimate Multisite بشكل متساوٍ مع كلا الخيارين، لكن هناك بعض الاختلافات المعمارية بين التكوينين.
في تكوين د ليل فرعي، يرث مواقع الشبكة مسارًا يعتمد على اسم النطاق الرئيسي. على سبيل المثال، سيحمل موقع الشبكة المسمى "site1" عنوان URL الكامل كـ https://domain.com/site1. في تكوين نطاق فرعي، سيحمل موقع الشبكة نطاقًا فرعيًا خاصًا به مشتقًا من اسم النطاق الرئيسي. وبالتالي، سيحمل موقع يُسمى "site1" عنوان URL الكامل كـ https://site1.domain.com/.
على الرغم من أن كلا الخيارين خياران صالحان، فإن استخدام النطاقات الفرعية يقدم عددًا من المزايا ولكنه يتطلب أيضًا تفكيرًا وتخطيطًا أكثر في بنيته.
من حيث DNS، يُقدّم استخدام الدلائل الفرعية تحديًا بسيطًا نسبيًا. بما أن مواقع الشبكة هي ببساطة أطفال للمسار الرئيسي، فإن إدخال اسم نطاق واحد فقط كافٍ للنطاق الرئيسي. بالنسبة لـ النطاقات الفرعية، التحدي أكثر تعقيدًا يتطلب إما إدخال CNAME منفصل لكل موقع شبكة أو إدخال wildcard (*) في سجلات DNS.
مجال آخر من الاعتبار هو SSL وإصدار واستخدام شهادات SSL. في تكوين دليل فرعي، يمكن استخدام شهادة نطاق واحدة لأن مواقع الشبكة هي ببساطة مسارات من اسم النطاق الرئيسي. وبالتالي، ستوفر شهادة domain.com SSL بشكل كافٍ لـ https://domain.com/site1، https://domain.com/site2 وهكذا.
في تكوين نطاق فرعي، يُعد استخدام شهادة SSL wildcard واحدة من أكثر الخيارات شيوعًا. توفر هذه الشهادة التشفير لنطاق وما النطاقات الفرعية الخاصة به. وبالتالي، ستوفر شهادة wildcard SSL التشفير لـ https://site1.domain.com، https://site2.domain.com و https://domain.com نفسه.
على الرغم من وجود خيارات أخرى، غالبًا ما تكون محدودة النطاق والتطبيق وتتطلب تكوينًا إضافيًا واعتبارات فيما يتعلق بالملاءمة.
الإضافات والسمات
ما يمنحه WordPress يُأخذ أيضًا، على الأقل من منظور العميل. في تثبيت WordPress مستقل، إذا قام مسؤول الموقع بتثبيت إضافة سيئة أو فشل في تحديث التثبيت، فإن الضحية الوحيدة هي نفسه. ومع ذلك، فإن تثبيت مسؤول موقع إضافة سيئة على تثبيت Multisite يخلق ضحية لكل موقع مثبت في الشبكة.
لهذا السبب، عند تكوينه كـ Multisite، يزيل WordPress القدرة من مسؤولي المواقع لتثبيت الإضافات والسمات، ويحول هذه القدرة إلى مسؤول شبكة جديد أو "super admin". يمكن لهذا الدور المتميز أن يقرر ما إذا كان يسمح لمسؤولي مواقع الشبكة برؤية أو الوصول إلى قائمة الإضافات في لوحة التحكم الخاصة بهم، وإذا كان الأمر كذلك، ما إذا كانت هذه الأذونات تمتد إلى تفعيل أو إلغاء تفعيل الإضافات.
إلى هذا الحد، يتحمل مسؤول الشبكة مسؤولية تثبيت الإضافات والسمات في الشبكة ويعطي أذونات لاستخدام هذه الإضافات والسمات للمواقع الشبكية. لا يمكن لمسؤولي المواقع تثبيت الإضافات والسمات أو الوصول إلى الإضافات والسمات غير المخصصة لموقعهم.
إعادة التأكيد على البيان أعلاه، على الرغم من أن حسابات المستخدمين تبدو مرتبطة بالموقع، في الواقع تُخصص إلى الشبكة وبالتالي يجب أن تكون فريدة عبر الشبكة. قد توجد حالات حيث تكون أسماء المستخدمين غير متاحة للتسجيل بسبب هذا السبب.
على الرغم من أنه ليس مفهومًا غريبًا في أنظمة المؤسسات، فإن مصدر تسجيل المستخدمين وتوثيقهم الوحيد غالبًا ما يكون مفهومًا صعبًا للفهم للأشخاص الذين يعتادون على تثبيتات WordPress مستقلة حيث يكون إدارة المستخدم أسهل بعض الشيء.
الوسائط
حيث تشترك مواقع الشبكة في قاعدة بيانات واحدة في WordPress Multisite، فإنها تحافظ على مسارات منفصلة على نظام الملفات لملفات الوسائط.
الموقع القياسي لـ WordPress (wp-content/uploads) يظل؛ ومع ذلك، يتم تعديل مساره ليعكس معرف الموقع الفريد. وبالتالي، تظهر ملفات الوسائط لموقع الشبكة كـ wp-contents/uploads/site/[id].
الروابط الدائمة
ذكرنا سابقًا أن هناك مزايا مميزة لـ نطاق فرعي على تكوين دليل فرعي وهنا: المسارات.
في تكوين دليل فرعي، يجب أن يشارك الموقع الرئيسي (الموقع الأول الذي تم إنشاؤه عند إنشاء الشبكة) ومواقع الشبكة الفرعية نفس المسار الذي يخرج من اسم النطاق. هذا قد يؤدي إلى عدد كبير من التعارضات.
بالنسبة للمشاركات، يتم إضافة مسار /blog/ إلزاميًا للموقع الرئيسي لمنع التعارضات مع مواقع الشبكة. هذا يعني أن الروابط الدائمة الجميلة مثل "Post name" ستُعرض كـ domain.name/blog/post-name/.
في تكوين نطاق فرعي، لا يلزم هذا الإجراء لأن كل موقع شبكة يستفيد من فصل النطاق الكامل وبالتالي لا يحتاج إلى الاعتماد على مسار واحد. بدلاً من ذلك، يحافظون على مساراتهم المميزة الخاصة استنادًا إلى النطاق الفرعي.
الصفحات الثابتة
في تكوين دليل فرعي، يمتد احتمال التعارض في الأسماء إلى الصفحات الثابتة لأن الموقع الرئيسي ومواقع الشبكة تشترك في نفس المسار.
لمنع ذلك، يوفر WordPress وسيلة لحظر بعض أسماء المواقع حتى لا تتعارض مع أسماء الموقع الأول. عادةً ما يدخل مسؤول الشبكة مسارات الجذر لصفحات الموقع الرئيسي.
في تكوين نطاق فرعي، يتم التخفيف من احتمال التعارض في الأسماء بواسطة النطاق الفرعي لأنه فريد للموقع الشبكي وليس مرتبطًا بأي شكل من الأشكال بالموقع الرئيسي.
التسجيل
في إعدادات الشبكة لـ WordPress Multisite، تتوفر خيارات تسجيل مستخدم جديدة وموجودة، مما يسمح للمستخدمين الجدد والحاليين بإنشاء مواقع.
على عكس تثبيتات WordPress مستقلة، لا تحتفظ مواقع الشبكة بالخيارات المألوفة للسماح بتسجيل المستخدمين أو تعيين تل ك التسجيلات إلى أدوار.
عندما يتم إنشاء حسابات المستخدم، يتم إنشاؤها على مستوى الشبكة. وبالتالي، بدلاً من الانتماء إلى موقع محدد، ينتمي إلى الشبكة. هذا له بعض المزايا والعيوب المميزة.
على سبيل المثال، افترض أن WordPress Multisite الخاص بك كان في مجال الأخبار والمعلومات. ستنشئ الشبكة ثم تُنشئ مواقع شبكة للمالية والتكنولوجيا والترفيه ومجالات اهتمام أخرى مع الحفاظ على السيطرة الكلية على الإضافات والسمات. كل موقع شبكة سيحصل بدوره على مستوى أعلى من التحكم في المظهر والملمس وتجربة المستخدم لموقعه الشبكي مقارنة بأنواع المنشورات المخصصة أو فئات المنشورات العادية.
إلى هذا الحد، عندما يسجل المستخدم الدخول، يسجل الدخول إلى الشبكة وفي النهاية يُسجّل الدخول إلى كل موقع شبكة أيضًا لتوفير تجربة سلسة. إذا كان موقعك الجديد يعتمد على الاشتراك، فستكون هذه هي الحل المثالي والنتيجة.
إذا كان الهدف والغاية من Multisite هو تقديم مواقع شبكة متباينة لا علاقة لها ببعضها البعض، فمن المحتمل دائمًا أن يتطلب ذلك إضافات خارجية أو إضافات إضافية للتلاعب بأدوار المستخدم.
النطاق و SSL
دعونا نتحدث عن تثبيت WordPress Multisite الذي يكاد ينساه اهتمامنا - Wordpress.com. هذا هو المثال الأكثر شمولًا لـ WordPress Multisite ويظهر قدراته الواسعة لتخصيصه وتشكيله لتلبية غرض.
في هذه الأيام على الإنترنت الحديث، يُعد استخدام SSL شبه إلزامي، ويواجه مسؤولو الشبكة لـ WordPress Multisite بسرعة هذه التحديات.
في تكوين نطاق فرعي، تُنشئ مواقع الشبكة استنادًا إلى اسم النطاق الجذري. وبالتالي، سيُنشئ موقع يُسمى "site1" كـ "site1.domain.com". باستخدام شهادة SSL wildcard، يمكن لمسؤول الشبكة التعامل مع هذه التحديات وتوفير قدرات تشفير SSL للشبكة.
يحتوي WordPress Multisite على وظيفة خريطة النطاق تسمح بربط مواقع الشبكة بأسماء نطاقات مخصصة أو أسماء نطاقات مختلفة عن النطاق الجذري للشبكة.
للمسؤولين الشبكيين، يُقدّم ذلك طبقة إضافية من التعقيد في كل من تكوين اسم النطاق وكذلك إصدار وصيانة شهادات SSL.
إلى هذا الحد، بينما يوفر WordPress Multisite وسيلة لتمكين www.anotherdomain.com للربط بـ "site1"، يترك مسؤول الشبكة مع التحدي لإدارة إدخالات DNS الخارجية وتنفيذ شهادات SSL.
Ultimate Multisite
مع فهم الاختلافات بين تثبيت WordPress مستقل وتثبيت Multisite، دعونا نلقي نظرة على كيف يُعد Ultimate Multisite الأسلحة النهائية لتقديم Websites as a Service.
مقدمة
Ultimate Multisite هو سكين الجيش السويسري الخاص بك عندما يتعلق الأمر بإنشاء موقع كخدمة (WaaS). فكر في Wix.com، Squarespace، WordPress.com ثم فكر في امتلاك خدمتك الخاصة.
تحت الغطاء، يستخدم Ultimate Multisite WordPress Multisite لكنه يفعل ذلك بطريقة لا تحل فقط مجموعة التحديات التي يواجهها مسؤولو الشبكة مع تثبيتات Multisite بل يعزز القدرات لتدعم مجموعة واسعة من حالات الاستخدام.
في الأقسام التالية، سنلقي نظرة على بعض حالات الاستخدام الشائعة والاعتبارات المطلوبة لدعم تلك الحالات.
حالات الاستخدام
الحالة 1: وكالة
عادةً ما تكمن المهارات الأساسية لوكالة في تصميم مواقع الويب مع جوانب مثل الاستضافة أو التسويق كخدمات إضافية.
للوكالات، يقدم Ultimate Multisite قيمة استثنائية في قدرته على استضافة وإدارة مواقع متعددة على منصة واحدة. أكثر من ذلك، للوكالات التي تُحاكي تصميماتها على سمات معينة مثل GeneratePress، Astra، OceanWP أو غيرها، يمكنهم الاستفادة من قدرات Ultimate Multisite لتفعيل هذه السمات تلقائيًا لكل موقع جديد.
وبالمثل مع وفرة العروض لأسعار الوكالات للإضافات الشائعة والشعبية، يتيح استخدام Ultimate Multisite للوكالات الاستفادة من الاستثمارات الحالية من خلال توفير منصة مشتركة يمكن تثبيت الإضافات عليها، وصيانتها واستخدامها.
من المحتمل أن يكون التكوين مطلوبًا، ولحسن الحظ، يجعل Ultimate Multisite من السهل جدًا تسهيل خريطة النطاق وشهادات SSL مع تكاملاته للعديد من مزودي الاستضافة الشهيرين بالإضافة إلى خدمات مثل Cloudflare و cPanel.
بالتالي، من خلال الاستفادة من أحد هؤلاء المزودين أو وضع Ultimate Multisite خلف Cloudflare، تصبح إدارة النطاقات وشهادات SSL أمرًا بسيطًا.
تفضل الوكالات التي تفضل الحفاظ على تحكم ضيق في إنشاء المواقع ستقدّر سهولة إنشاء المواقع وربطها بالعملاء والخطط عبر واجهة Ultimate Multisite المبسطة.
يتم الحفاظ على تحكم ضيق في الإضافات والسمات على أساس المنتج من خلال واجهات Ultimate Multisite البديهية التي تسمح بتفعيل أو إخفاء الإضافات والسمات وكذلك حالة التفعيل عند إنشاء موقع جديد.
توفر السمات وظائف مماثلة، مما يسمح بتفعيل أو إخفاء سمات معينة عند إنشاء الموقع.
ستجد الوكالات راحة البال مع Ultimate Multisite التي تسمح لهم بالقيام بما يفعلونه أفضل - تصميم مواقع ويب استثنائية.
الحالة 2: مزود متخصص
هناك قول شائع يقول، "افعل شيئًا واحدًا وافعلها جيدًا". للعديد من المتخصصين هذا يعني إنشاء منتج أو خدمة حول فكرة أساسية واحدة.
ربما أنت لاعب جولف شغوف يروج لمواقع للنوادي أو ربما أنت لاعب ألعاب إلكترونية يقدم مواقع للقبائل. أو شخص يروج لخدمة حجز للمطاعم؟
لعدة أسباب، سترغب في تقديم خدمات استنادًا إلى إطار عمل ومنصة مشتركة. قد يكون ذلك لأنك قد صمم أو استثمرت في إضافات مخصصة لتوفير الوظائف المطلوبة أو قد يكون ذلك لأن أفضل الممارسات الصناعية تتطلب نوعًا من النهج الموحد في التصميم.
إحدى ميزات Ultimate Multisite المبتكرة هي استخدام مواقع القالب. موقع القالب هو حيث تم تثبيت وتفعيل السمة، وتثبيت وتفعيل الإضافات الضرورية، وإنشاء مشاركات أو صفحات نموذجية. عندما ينشئ عميل موقعًا جديدًا استنادًا إلى القالب، يتم نسخ محتويات وإعدادات القالب إلى الموقع الجديد.
للمزودين للمواقع المتخصصة والخدمات، يوفر هذا ميزة لا تضاهى في القدرة على إنشاء موقع جاهز على الفور مع إضافات مخصصة وتصميم. يحتاج العميل فقط إلى تقديم أدنى مدخلات لإكمال الخدمة.
اعتمادًا على المتطلبات، قد تناسب تكوينات دليل فرعي أو نطاق فرعي، وفي هذه الحالة ستكون خيارات البنية بين شهادة SSL بسيطة لـ الدلائل الفرعية أو شهادة SSL wildcard لـ النطاقات الفرعية.
الحالة 3: استضافة WordPress
هناك عدد لا يحصى من الطرق لاستضافة مواقع WordPress لكن نادرًا ما يكون الأمر بسيطًا مثل توفير مساحة ويب لعميل مع نسخة WordPress مثبتة مسبقًا. هذا لأن عددًا من القرارات والاعتبارات يجب أن تتحد لتقديم خدمة ذات مغزى.
يتميز Ultimate Multisite في هذا المجال بتقديم حل شامل جاهز للتشغيل لاستضافة مواقع WordPress. يتضمن الحل الآليات الأساسية لتقديم خدمات الاشتراك، جمع المدفوعات، نماذج الدفع، قسائم الخصم، والاتصالات مع العملاء.
جزء كبير من العمل الأساسي المطلوب لتثبيت، تكوين، وصيانة WordPress Multisite يتم تسهيله بواسطة Ultimate Multisite إلى الحد الذي يحتاج فيه مسؤولو الشبكة فقط إلى التفكير في الجوانب المتعلقة بخدمتهم أو تخصصهم مثل مستويات المنتج، التسعير، وعروض الخدمة.
للمطورين الذين يرغبون في التكامل مع Ultimate Multisite، يقدم الحل أيضًا RESTful API شاملة وWebhooks لإشعار الأحداث.
دون الاعتماد على عدد لا يحصى من الإضافات الخارجية والتراخيص، يوفر Ultimate Multisite حلًا غنيًا بالميزات ومقارنًا مع Wix، Squarespace، WordPress.com وغيرها.
اعتبارات البنية
بينما ليست دليلًا شاملاً، يجب أن تخدم العناصر التالية كدليل لاختيار التقنيات الصحيحة لدعم تثبيت Ultimate Multisite.
الاستضافة المشتركة مقابل المخصصة
لسوء الحظ، ليس جميع مزودي الاستضافة متساوون وبعضهم يمارس كثافة خوادم شديدة. عادةً ما يحقق مزودون منخفضي التكلفة إيرادات من خلال تعظيم كثافة الخادم. وبالتالي، قد يكون تثبيت Ultimate Multisite الخاص بك هو واحد فقط من مئات المواقع على نفس الخادم.
بدون تدابير مناسبة من المزود، يعاني مواقع الخادم المشترك من مشكلة "الجار الصاخب". أي، موقع على نفس الخادم يستهلك تلك الموارد التي يتعين على مواقع أخرى التنافس عليها. غالبًا ما يظهر ذلك كمواقع بطيئة أو لا تستجيب في الوقت المناسب.
كموفر استضافة ويب بنفسك، سيؤدي ذلك إلى أن يواجه عملاؤك سرعات سيئة، ترتيب صفحة منخفض، ومعدلات ارتداد عالية غالبًا ما تؤدي إلى فقدان العملاء بينما يبحثون عن خدمات أخرى.
باختصار، الرخيص لا يعني جيدًا.
يُعرف Ultimate Multisite بالعمل مع عدد من مزودي الاستضافة الجيدين ويتكامل جيدًا مع بيئتهم لتوفير وظائف مثل خريطة النطاق وتشفير SSL التلقائي. يقدّر هؤلاء المزودون الأداء ويقدمون خدمة أعلى من الاستضافة المشتركة.
للحصول على قائمة بالمزودين المتوافقين وتعليمات الإعداد الكامل لكل منهم، يرجى التحقق من وثائق مزودي الخدمة المتوافقين.
اعتبارات الأداء
Ultimate Multisite ليس تطبيقًا بطيئًا، بل هو سريع بشكل ملحوظ. ومع ذلك، يؤدي فقط إلى الأداء الجيد كما هو الحال في التطبيق والبنية التحتية الأساسية ويمك نه الاستفادة فقط مما يملكه.
فكر في هذا: أنت مسؤول شبكة لتثبيت Ultimate Multisite مع 100 موقع. بعض تلك المواقع تعمل جيدًا وتستقطب عددًا من زوار الموقع يوميًا.
سيكون هذا السيناريو مختلفًا على نطاق أصغر مثل واحد إلى خمسة مواقع، لكن قبل وقت قصير ستظهر مشاكل الحجم.
إذا تُرك دون رعاية، سيكون موقع Ultimate Multisite الوحيد مسؤولًا عن تلبية طلبات جميع الزوار للمواقع. قد تكون هذه الطلبات لصفحات PHP ديناميكية أو أصول ثابتة مثل أوراق الأنماط، جافا سكريبت أو ملفات الوسائط. سواء كان هناك موقع واحد أو مائة، تصبح هذه المهام متكررة، مملة ومهدرة. لا حاجة لاستخدام قوة المعالج والذاكرة لمعالجة ملف PHP عندما يكون المخرج هو نفس المعلومات الثابتة لكل طلب.
وبالمثل، طلب واحد لصفحة PHP أو HTML يولد طلبات متتالية للبرامج النصية، أوراق الأنماط، وملفات الصور. تلك الطلبات موجهة مباشرة إلى خادم Ultimate Multisite الخاص بك.
يمكن حل هذه المشكلة بسهولة عن طريق ترقية الخادم، لكنها لا تحل مشكلة التأخير الجغرافي. لا يمكن لخوادم متعددة في مواقع متعددة معالجة هذه المشكلة بشكل صحيح.
لهذا السبب، غالبًا ما يستخدم مسؤولو الشبكة حلول التخزين المؤقت للواجهة الأمامية وشبكات توزيع المحتوى (CDN) لتلبية طلبات الصفحات الثابتة. تلبية هذه الطلبات وتقديم الأصول قبل وصول الطلب إلى الخادم يوفر موارد المعالجة، ويزيل التأخير، ويتجنب التحديثات غير الضرورية ويزيد من استثمارات التكنولوجيا.
يحتوي Ultimate Multisite على إضافة Cloudflare متقدمة تمكّن مسؤولي الشبكة من وضع تثبيتاتهم خلف Cloudflare واستخدام ليس فقط قدراته على التخزين المؤقت ولكن أيضًا استضافة DNS، شهادات SSL وآليات الأمان أيضًا.
النسخ الاحتياطي
يمكن أن يطلب 50 شخصًا نصيحة حول النسخ الاحتياطي وتلقي 50 رأيًا مختلفًا حول استراتيجيات النسخ الاحتياطي. الجواب هو، يعتمد ذلك.
ما لا يُنزع من الجدال هو أن النسخ الاحتياطي مطلوب وأنه من غير المعقول تقريبًا أن لا تُدار هذه النسخ الاحتياطي من قبل المزود، خاصةً المزود الذي يقدم خدمة مُدارة. وبالتالي، سيبحث العملاء عن مسؤول الشبكة لتوفير وإدارة هذه الخدمة. من يذهب مسؤول الشبكة إليه هو مشكلة مختلفة تمامًا.
لأغراض هذا القسم، دعونا نتفق على أن النسخ الاحتياطي هو نسخة في لحظة زمنية من حالة النظام في وقت بدء النسخ الاحتياطي. ببساطة، ما هو حالة النظام في وقت النسخ الاحتياطي يتم التقاطها وتخزينها في النسخ الاحتياطي.
مع ه ذا الفهم، ستعتمد إجابة كيفية تحقيق النسخ الاحتياطي وما هو الأفضل لبيئتك على متطلباتك وقدرة مزود الاستضافة على تلبية تلك المتطلبات. ومع ذلك، في ترتيب من الأكثر رأيًا إلى الأقل رأيًا، يجب أن توفر الخيارات التالية بعض التوجيه.
اللقطات
اللقطات هي الأسلحة الفضية للنسخ الاحتياطي لأنها سهلة، غير معقدة (حتى عندما تريد الاستعادة) و"تعمل ببساطة". لكنها تتطلب بعض المساعدة من مزودك، وتطبق في الغالب فقط إذا كان لديك VPS (خادم خاص افتراضي) أو مشابه. يقدم عدد من مزودي الخدمة المذكورين في وثائق "مزودي الخدمة المتوافقين" نسخ احتياطي لا تتطلب تدخلًا إضافيًا أو اعتبارًا من مسؤول الشبكة.
حيث تستهدف النسخ الاحتياطي التقليدي الملفات وقواعد البيانات، تستهدف اللقطة كامل القرص. هذا يعني أنه لا يتم التقاط بيانات الموقع فقط في اللقطة، بل نظام التشغيل والتكوين أيضًا. بالنسبة للعديد، هذا ميزة مميزة لأن نظامًا جديدًا يمكن إنشاؤه تقريبًا على الفور من اللقطة وتفعيله لاستبدال نسخة مريضة. وبالمثل، عملية الاستعادة لاسترجاع الملفات تتطلب فقط إرفاق صورة اللقطة كقرص إلى نسخة موجودة حت ى يمكن الوصول إلى الملفات ونسخها.
قد تجذب اللقطات تكلفة إضافية مع مزود الاستضافة، لكنها بوليصة تأمين ضد الحوادث.
السكربتات الخارجية
يبدو أنه لا يوجد نقص في السكربتات والحلول الخارجية للنسخ الاحتياطي لموارد WordPress و MySQL، وهذه ستعمل جيدًا مع Ultimate Multisite لأنه إضافة WordPress تستخدم نظام الملفات وقاعدة البيانات. وبالتالي، حل ينسخ احتياطي مواقع WordPress سيغطي احتياجات Ultimate Multisite بشكل كافٍ.
لا يمكننا التوصية بأي سكربت على آخر، لكن نصيحتنا العامة هي تشغيل عدة اختبارات نسخ احتياطي واستعادة لضمان أن النتائج مرغوبة ولـ "تأكد من التأكد" من خلال تقييم السكربت ووظائفه باستمرار، خاصةً حيث يتم تطبيق استراتيجية نسخ احتياطي تفاضلية.
يجب ملاحظة أن هذه السكربتات، أثناء التشغيل، ستزيد من عبء النظام الذي يجب أخذه في الاعتبار.
الإضافات
لا توجد مشكلة تقريبًا في WordPress لا يمكن حلها بإضافة، وإذا كان إدارة السكربتات الخارجية ليست مشروبك، فقد تكون الإضافة الخيار التالي الأفضل.
بينما تختلف الإضافات في الخيارات والميزات، فإنها غالبًا ما تؤدي نفس الوظيفة وهي إنشاء نسخة من ملفات WordPress ومحتويات قاعدة البيانات. بعد ذلك، تختلف الوظائف حيث يمكن لبعض الإضافات إرسال النسخ الاحتياطي إلى خدمات خارجية مثل Google Drive أو Dropbox أو إلى خدمة تخزين كائنات متوافقة مثل S3، Wasabi أو غيرها. توفر الإضافات الأكثر شمولًا نسخًا احتياطية تفاضلية أو استراتيجية ما لتخزين البيانات التي تم تغييرها فقط لتوفير تكاليف التخزين الخارجية.
في اختيارك للإضافة، تأكد من التحقق من أنها تدعم Multisite. بسبب طبيعة التشغيل أثناء النسخ الاحتياطي، يمكنك توقع عبء مؤقت على الخادم حتى يتم إكمال العملية.
النطاق و SSL
لقد نوقش بالفعل كثيرًا حول أسماء النطاق في وضع Multisite نطاق فرعي. حل شائع جدًا لمسؤولي الشبكة هو استخدام إدخالات DNS wildcard.
ستحل هذه النوعية من إدخالات DNS بنجاح النطاقات الفرعية مثل 'site1.domain.com' و 'site2.domain.com' إلى عنوان IP 1.2.3.4، مما يدعم Ultimate Multisite وبشكل أكبر WordPress Multisite في وضع نطاق فرعي.
قد يعمل هذا تمامًا للـ HTTP لأن المضيف الهدف يُقرأ من رؤوس HTTP، لكن نادرًا ما يكون الويب بسيطًا هذه الأيام حيث أن معاملات HTTPS الآمنة شبه إلزامية.
لحسن الحظ، هناك خيارات سهلة لشهادات SSL. في وضع دليل فرعي، يمكن استخدام شهادة نطاق عادية. تتوفر هذه بسهولة ومجانية من مزودي الاستضافة الذين قد يستخدمون خدمة LetsEncrypt المجانية أو مصدرًا آخر. وإلا، فهي متاحة تجاريًا من السلطات إذا كنت قادرًا على إنشاء طلب توقيع شهادة.
في وضع نطاق فرعي، ستتطابق شهادة SSL wildcard تمامًا مع نطاق wildcard وتسمح للشهادة بأن تكون سارية على النطاق الجذري وجميع النطاقات الفرعية دون تكوين إضافي.
مع ذلك، يجب ملاحظة أن شهادات SSL wildcard قد لا تعمل مع خدمات مثل Cloudflare ما لم تكن على خطة مؤسسة أو ضبط الإدخال إلى DNS فقط، في هذه الحالة يتم تجاوز كل التخزين المؤقت والتحسين.
من خلال الإضافة المدمجة في Ultimate Multisite، يمكنك حل هذه المشكلة، حيث تُظهر خبرتنا الواسعة مع احتياجات WordPress Multisite. عند تفعيل هذه الإضافة البسيطة، سيستخدم Ultimate Multisite بيانات اعتماد Cloudflare الخاصة بك لإضافة إدخالات DNS تلقائيًا لمواقع الشبكة في Cloudflare وتعيين وضعها إلى "proxied". بهذه الطريقة، كل موقع فرعي في الشبكة، عند إنشائه، سيحصل على الحماية الكاملة وفوائد Cloudflare بما في ذلك SSL.
اعتمادًا على طبيعة ووظيفة تثبيت Ultimate Multisite الخاص بك، قد يكون هناك حاجة للعملاء لاستخدام نطاقاتهم الخاصة. في هذه الحالة، يُحمّل مسؤول الشبكة حلًّا لاثنين من المشكلات. أولًا، استضافة اسم النطاق، وثانيًا، شهادات SSL للنطاق.
بالنسبة للعديد، يُعد استخدام Cloudflare خيارًا سهلًا. يحتاج العميل فقط إلى وضع نطاقه على Cloudflare، وتوجيه CNAME إلى النطاق الجذري لـ Ultimate Multisite، ورسم نطاقه في Ultimate Multisite لبدء الاستفادة من اسم نطاقه المخصص.
خارج هذا، يجب البحث عن حلول بديلة، ولهذا يوصي Ultimate Multisite بقائمة مزودي الخدمة المتوافقين. هذا لأن إعداد DNS و SSL قد يكون عملية غير بسيطة. ومع ذلك، مع تكامل Ultimate Multisite مع هؤلاء المزودين، يتم إزالة التعقيد وتُؤتمت العملية.
الإضافات
من المحتمل جدًا أن تحتاج إلى إضافات إضافية لتوفير وظائف لعملائك أو مواقع الشبكة. هل تعمل جميع الإضافات مع WordPress Multisite و Ultimate Multisite؟ حسنًا، يعتمد ذلك.
بينما يمكن تثبيت معظم الإضافات في WordPress Multisite، يختلف تفعيلها وترخيصها من مؤلف إلى آخر.
التحدي يكمن في كيفية تطبيق الترخيص مع بعض الإضافات التي تتطلب ترخيصًا على أساس النطاق. هذا يعني أنه لبعض الإضافات، يحتاج مسؤول الشبكة إلى تفعيل الترخيص يدويًا لكل إضافة على كل موقع جديد.
لذلك قد يكون من الأفضل التحقق مع مؤلف الإضافة لمعرفة كيف ستعمل مع WordPress Multisite وأي متطلبات خاصة أو إجراءات مطلوبة لترخيصها.