الجامعة لا تكون أبدًا موقعًا واحدًا. فهي الموقع المؤسسي الرئيسي، بالإضافة إلى مواقع منفصلة لكل كلية وقسم ومركز أبحاث ومكتبة، وغالبًا عشرات المشاريع والمختبرات والفعاليات الفردية. يمكن لجامعة كبيرة أن تدير بسهولة ما بين 50 إلى عدة مئات من المواقع المستقلة. التحدي ليس في بناء أي موقع بمفرده — بل في إدارتها جميعًا معًا: الحفاظ على أمانها واتساقها مع الهوية المؤسسية وتحديثها دون الحاجة إلى فريق منفصل ومجموعة تقنيات منفصلة لكل موقع. هذه هي المشكلة التي صُمم دروبال متعدد المواقع (Drupal Multisite) لحلها، وهي جزء كبير من سبب اعتماد الكثير من أفضل الجامعات في العالم على دروبال.
يشرح هذا المقال كيفية عمل دروبال متعدد المواقع، ولماذا يناسب حالة استخدام الجامعات بهذا الشكل الجيد، وكيف يُقارن بالبدائل المتاحة — وبنفس القدر من الأهمية — متى يكون الخيار الخاطئ. الهدف هو تقديم صورة واضحة وصادقة تساعد المؤسسة على تحديد ما إذا كانت بنية تعدد المواقع هي المعمارية المناسبة لمنظومة مواقعها الإلكترونية.
مشكلة تعدد المواقع التي تواجهها كل جامعة
الجامعات لا مركزية بطبيعتها. كل كلية تريد التحكم في موقعها الخاص، وكل قسم له محتواه ومحرروه، وتكون تقنية المعلومات المركزية مسؤولة عن الحفاظ على أمان المنظومة بأكملها وإتاحتها واتساقها. وإذا تُركت هذه الحالة دون إدارة، تنشأ فوضى مألوفة: تنشئ الأقسام مواقعها الخاصة غير المعتمدة على أي منصة متاحة، وينهار اتساق الهوية البصرية، وتُطبَّق تحديثات الأمان بشكل غير متكافئ أو لا تُطبَّق إطلاقًا، ولا يملك أحد صورة كاملة عما يعمل فعليًا.
بعبارة أخرى، فإن قرار اختيار المنصة هو في جوهره قرار حوكمة مُقنَّع. فالسؤال الذي يجب على الجامعة الإجابة عنه ليس فقط "أي نظام إدارة محتوى يجب أن نستخدم" بل "كيف نسمح لعشرات الفرق بإدارة مواقعها الخاصة بينما تحافظ تقنية المعلومات المركزية على أمان المنظومة بأكملها وتماسكها؟" ويُعد دروبال متعدد المواقع أحد أقوى الإجابات على هذا السؤال بالتحديد.
ما هو دروبال متعدد المواقع فعليًا
يُعد دروبال أحد الأنظمة القليلة لإدارة المحتوى التي تدعم تعدد المواقع بشكل أصلي ضمن نواتها. دروبال متعدد المواقع هو تثبيت واحد لدروبال يُشغّل عدة مواقع إلكترونية من قاعدة برمجية واحدة مشتركة. التفصيل التقني المهم هو ما الذي يُشارَك وما الذي لا يُشارَك: تشترك المواقع في الكود — نواة دروبال والوحدات (modules) والقوالب (themes) — لكن لكل موقع قاعدة بيانات منفصلة خاصة به. وهذا يعني أن المحتوى والإعدادات والمستخدمين والملفات المرفوعة منفصلة تمامًا لكل موقع، رغم أنها جميعًا تعمل على نفس التثبيت الأساسي.
من الناحية الآلية، يقع كل موقع في مجلد فرعي خاص به ضمن التثبيت، وله ملف إعدادات خاص به يُشير إلى قاعدة بياناته الخاصة. وعندما يصل طلب ما، يتحقق دروبال من النطاق أو الرابط ويُحمّل قاعدة بيانات الموقع الصحيح وإعداداته. والنتيجة العملية هي مجموعة من المواقع تبدو وتعمل كمواقع إلكترونية مستقلة تمامًا — لكل منها هويته البصرية ومحتواه وفريقه التحريري الخاص — بينما تشترك جميعها تحت السطح في قاعدة برمجية واحدة وعملية تحديث واحدة. حدِّث الكود مرة واحدة، وستعمل كل المواقع بالنسخة الجديدة.
لماذا تعتمد الجامعات على تعدد المواقع
يتماشى نموذج تعدد المواقع بشكل شبه مثالي مع الطريقة التي تعمل بها الجامعة فعليًا. تُشغّل ستانفورد وييل وهارفارد وديوك جميعها منصات مواقع دروبال كبيرة خاصة بها على هذا المبدأ، وتُدير مؤسسات مثل كلية لندن الجامعية (UCL) 500 موقع مصغر أو أكثر من طبقة حوكمة واحدة. والمزايا التي تجعل هذا النموذج ناجحًا ملموسة:
- تحديث مرة واحدة، ونشر في كل مكان: يُطبَّق تصحيح أمني أو ترقية إصدار دروبال على القاعدة البرمجية المشتركة مرة واحدة، ويسري مفعوله عبر كل موقع. فبدلاً من تصحيح 200 موقع بشكل فردي، تُجري تقنية المعلومات المركزية تحديثًا واحدًا — وهو أكبر توفير تشغيلي يُقدّمه تعدد المواقع.
- حوكمة مركزية مع استقلالية محلية: تُدير تقنية المعلومات المركزية البنية المعمارية والأمان ونظام التصميم، بينما تحتفظ كل كلية وقسم بالتحكم التحريري الكامل في محتواه الخاص. تحصل الأقسام على استقلاليتها، وتحافظ المؤسسة على تماسكها.
- اتساق الهوية البصرية على نطاق واسع: يعني وجود نظام تصميم ومكونات مشتركة أن كل موقع يمكن أن يحمل هوية بصرية متسقة ومعايير إتاحة موحدة، بدلاً من أن ينحرف كل موقع في اتجاهه الخاص.
- تطوير مشترك: تُبنى الوظائف المخصصة مرة واحدة وتُتاح لكل المواقع. فأي وحدة أو ميزة طُوّرت لكلية معينة يمكن تفعيلها للكليات الأخرى دون إعادة بنائها.
- إضافة مواقع جديدة بكفاءة: عندما يحتاج قسم أو برنامج جديد إلى موقع، يمكن توفيره بسرعة من المنصة المشتركة، بدءًا من نفس الأساس الآمن والمتاح والمتسق مع الهوية البصرية بدلاً من البدء من الصفر.
بالنسبة لمؤسسة تُدير منظومة كبيرة من المواقع، تتراكم هذه الكفاءات وتتضاعف فوائدها. وهذا هو بالضبط النمط الكامن وراء هيمنة دروبال في قطاع التعليم العالي، ويرتبط ارتباطًا مباشرًا بنقاط قوة المنصة الأوسع في هذا القطاع، والتي نتناولها في نظرتنا العامة على دروبال في التعليم.
تعدد المواقع الكلاسيكي ليس الخيار الوحيد
تعدد المواقع الكلاسيكي هو إحدى طرق تشغيل عدة مواقع من دروبال، لكنه ليس الطريقة الوحيدة. ويوفر اختيار البنية المعمارية الصحيحة منذ البداية وقتًا وتكلفة كبيرة لاحقًا، لذا يستحق الأمر فهم البدائل الرئيسية.
| الأسلوب | كيف يعمل | الأنسب لـ |
|---|---|---|
| تعدد المواقع الكلاسيكي | قاعدة برمجية واحدة، وقاعدة بيانات منفصلة لكل موقع. المحتوى معزول تمامًا. | عدد كبير من المواقع المتشابهة هيكليًا وتحتاج إلى فصل قوي للمحتوى. |
| Domain Access | قاعدة برمجية واحدة وقاعدة بيانات واحدة مشتركة؛ وحدة تتحكم في المحتوى الذي ينتمي إلى كل نطاق. | مواقع تشترك في قدر كبير من المحتوى والمحررين، وتُدار مركزيًا. |
| تثبيتات منفصلة | كل موقع هو تثبيت دروبال مستقل بذاته، غالبًا ما يُدار عبر سير عمل Composer مشترك. | مواقع تختلف بشكل كبير عن بعضها، أو تحتاج إلى عزل كامل وتوسع مستقل. |
| التوزيعة / النسخة الأساسية (Upstream) | يُجهَّز بناء دروبال موحّد ويُستخدم كنقطة انطلاق لكل موقع جديد مستقل. | إطلاق عدد كبير من المواقع من أساس مشترك مع الحفاظ على استقلاليتها. |
التمييز الجوهري هو بين عزل المحتوى ومشاركة المحتوى. يمنح تعدد المواقع كل موقع قاعدة بياناته الخاصة وأقوى درجة من الفصل. أما Domain Access فتشترك في قاعدة بيانات واحدة، مما يسهّل مشاركة المحتوى والمحررين لكنه يربط المواقع ببعضها بشكل وثيق. وتمنح التثبيتات المنفصلة أعلى درجة من العزل والاستقلالية على حساب إدارة كل موقع بشكل فردي. ويعتمد الاختيار الصحيح على ما إذا كانت مواقعك تنويعات على نفس الفكرة ينبغي أن تتشارك، أم منظومات مستقلة فعليًا لا ينبغي أن تتشارك.
المفاضلات الصادقة: متى يكون تعدد المواقع خيارًا خاطئًا
تعدد المواقع قوي، لكنه ليس خاليًا من المخاطر، ويجب على أي تقييم مسؤول أن يوازن السلبيات بنفس جدية الفوائد. إن كفاءة القاعدة البرمجية المشتركة هي أيضًا نقطة ضعفها الأساسية: فهي تخلق نقطة فشل واحدة.
- مصير مشترك: بما أن كل المواقع تعمل على قاعدة برمجية واحدة، فإن أي مشكلة في تلك القاعدة تؤثر على كل المواقع في آن واحد. فارتفاع مفاجئ في حركة الزيارات على موقع واحد يمكن أن يُضعف الأداء لكل المواقع الأخرى، كما أن اختراقًا أمنيًا يصعب احتواؤه — فإذا اختُرق موقع واحد عبر الكود المشترك، فقد تتعرض بقية المواقع للخطر أيضًا.
- عزل محدود: لا يوجد فصل قوي بين المواقع على مستوى الكود، وهو أمر يستحق اعتبارًا حقيقيًا للمؤسسات ذات متطلبات الأمان أو الامتثال الصارمة. وحيثما يجب أن تكون المواقع معزولة تمامًا، تكون التثبيتات المنفصلة النموذج الأكثر أمانًا.
- ترابط الصيانة: قد تتطلب بعض العمليات، مثل بعض الترقيات، دخول كل المواقع إلى وضع الصيانة معًا، كما أن فصل موقع واحد لاحقًا من بنية تعدد مواقع ليست مهمة بسيطة.
- التباعد مع الوقت: إذا تباعدت المواقع في احتياجاتها البرمجية أو الإعدادية، فقد ينقسم مسار الترقية المشترك، وتبدأ البساطة التي بررت اختيار تعدد المواقع بالتآكل.
جعلت سير عمليات دروبال الحديثة البدائل أكثر جاذبية مما كانت عليه في السابق. فسير عمل قائم على Composer يُدير تثبيتات منفصلة، أو منصة توفر مواقع معزولة من نسخة أساسية مشتركة، يمكن أن يوفر قدرًا كبيرًا من اتساق تعدد المواقع دون مخاطر المصير المشترك. يظل تعدد المواقع خيارًا ممتازًا لمنظومة كبيرة من المواقع المتشابهة والمحكومة مركزيًا — لكن بالنسبة للمواقع التي تحتاج إلى عزل حقيقي، أو توسع مستقل، أو تباعد كبير، فغالبًا ما يكون الأداة الخاطئة. والقاعدة الصادقة هي اختيار تعدد المواقع لأن مواقعك متشابهة فعليًا ومحكومة مركزيًا، وليس لمجرد أنه يبدو وكأنه يُقلل عدد المواقع.
الحوكمة: السبب الحقيقي وراء أهمية هذا الأمر
تحت السطح المعماري التقني، ما تشتريه الجامعة فعليًا مع تعدد المواقع هو نموذج حوكمة. فأصعب مشكلة في إدارة مواقع الجامعة الإلكترونية ليست بناء المواقع — بل تنسيق عمل عشرات الفرق المستقلة دون خنق استقلاليتها أو فقدان السيطرة المركزية.
تحل منصة تعدد مواقع مُدارة جيدًا هذا التوتر بشكل واضح. تمتلك تقنية المعلومات المركزية الطبقة المشتركة: القاعدة البرمجية، وتحديثات الأمان، ونظام التصميم، ومعايير الإتاحة، والبنية المعمارية العامة. بينما تمتلك الكليات والأقسام محتواها: محرروها الخاصون، وجداول نشرهم الخاصة، وهيكل مواقعهم الخاص ضمن الإطار المشترك. وبما أن الأدوار والصلاحيات مُحددة مركزيًا، يحصل كل فريق على الصلاحيات التي يحتاجها بالضبط ولا شيء أكثر. والنتيجة هي استقلالية حيث تفيد — في المحتوى — واتساق حيث يهم — في الأمان والهوية البصرية والامتثال. هذا التوازن هو المنتج الحقيقي، وهو سبب كون اختيار المنصة قرار حوكمة في النهاية أكثر من كونه قرارًا تقنيًا بحتًا.
الأخطاء الشائعة في تعدد المواقع وكيفية تجنبها
- اختيار تعدد المواقع لتقليل عدد المواقع: السبب الصحيح لاستخدام تعدد المواقع هو التشابه الحقيقي والحوكمة المشتركة، وليس رقمًا أصغر على الخادم. اختر البنية المعمارية التي تناسب العلاقة الفعلية بين المواقع، لا تلك التي تبدو أكثر ترتيبًا.
- تجاهل نقطة الفشل الواحدة: القاعدة البرمجية المشتركة تعني مخاطر مشتركة. خطط لذلك بممارسات أمنية قوية، وهامش أداء كافٍ، وفهم واضح لما يحدث إذا واجه أحد المواقع يومًا سيئًا.
- إجبار مواقع مختلفة جدًا على الاندماج معًا: المواقع ذات الاحتياجات البرمجية أو الإعدادية شديدة التباين تُجهد النموذج المشترك. إذا كان التباعد حقيقيًا، فإن التثبيتات المنفصلة تخدم بشكل أفضل من فرض تعدد المواقع.
- التقليل من تقدير تكلفة الخروج: فصل موقع لاحقًا من بنية تعدد مواقع أمر صعب. خطط للبنية المعمارية مع وضع الفصل المستقبلي في الاعتبار، بدلاً من افتراض أن المواقع ستبقى معًا إلى الأبد.
- إهمال الحوكمة: التقنية وحدها لا تخلق النظام. فبدون نموذج واضح لمن يمتلك الطبقة المشتركة ومن يمتلك محتوى كل موقع، حتى بنية تعدد المواقع المبنية جيدًا تنحرف نحو الفوضى.
- السماح للمواقع بالتباعد دون إدارة: السماح لكل موقع بتراكم كوده المخصص الخاص يُقوّض ميزة القاعدة البرمجية المشتركة. حافظ على انضباط التخصيصات، وشاركها كلما أمكن ذلك.
عند إدارته بشكل جيد، يتيح دروبال متعدد المواقع للجامعة تشغيل منظومة مواقع إلكترونية كبيرة ومتماسكة من منصة واحدة — حيث تحافظ تقنية المعلومات المركزية على أمان كل شيء واتساقه مع الهوية البصرية، بينما تحتفظ كل كلية وقسم بالتحكم في موقعه الخاص. إنه أحد أوضح الأسباب التي جعلت دروبال الخيار الافتراضي في التعليم العالي، ويتكامل بشكل طبيعي مع نقاط قوة المنصة في المحتوى متعدد اللغات، والإتاحة، والتكامل مع الأنظمة الأكاديمية.
أسئلة شائعة حول دروبال متعدد المواقع
هل تشترك مواقع تعدد المواقع في المحتوى فيما بينها؟
ليس في تعدد المواقع الكلاسيكي. لكل موقع قاعدة بياناته الخاصة المنفصلة، لذا يكون المحتوى والمستخدمون والإعدادات معزولة — وتشترك المواقع فقط في الكود الأساسي. وإذا كانت مشاركة المحتوى بين المواقع متطلبًا، فهذه حالة تستدعي بنية معمارية مختلفة، مثل Domain Access، التي تستخدم قاعدة بيانات واحدة مشتركة وتتيح لك التحكم في المحتوى الذي يظهر على كل موقع. ويعتمد الاختيار بينهما على ما إذا كان ينبغي عزل مواقعك أم مشاركتها.
كم عدد المواقع التي يمكن أن يُشغّلها تعدد مواقع دروبال الواحد؟
لا يوجد حد ثابت، وتُدير المؤسسات الكبيرة أعدادًا كبيرة — فجامعات مثل كلية لندن الجامعية (UCL) تُدير 500 موقع أو أكثر، وتصل بعض عمليات النشر إلى المئات أو أكثر. ويتحدد السقف العملي بدرجة أقل بواسطة دروبال نفسه، وبدرجة أكبر بالبنية التحتية وانضباط الحوكمة ومدى تشابه المواقع. وكلما زاد عدد المواقع التي تُشغّلها على قاعدة برمجية واحدة، ازدادت أهمية الممارسات التشغيلية القوية والتخطيط للأداء، لأنها جميعًا تتشارك مصير تلك القاعدة البرمجية.
هل يتم التخلي عن دروبال متعدد المواقع؟
لا. تعدد المواقع ميزة أساسية قيّمة ولا يُجرى إزالتها. جرت نقاشات مجتمعية حول تحسين طريقة عمله مع الأدوات الحديثة مثل Composer، وقد تقدمت هذه التحسينات، لكن الميزة نفسها تظل مدعومة. مع ذلك، تُقدّم المنظومة الآن بدائل قوية — من بينها التثبيتات المنفصلة المُدارة عبر Composer والنسخ الأساسية القائمة على المنصات — لذا فإن السؤال الحديث لم يعد "هل تعدد المواقع متاح" بقدر ما هو "هل تعدد المواقع هو الخيار المناسب لهذه المنظومة تحديدًا".
تعدد المواقع أم التثبيتات المنفصلة — أيهما يجب أن تختار الجامعة؟
يعتمد الأمر على مدى تشابه المواقع ومدى الحاجة إلى عزلها. يناسب تعدد المواقع منظومة كبيرة من المواقع المتشابهة هيكليًا التي تتشارك نظام تصميم ويجب تحديثها معًا، مع حوكمة مركزية — وهو السيناريو الكلاسيكي لمواقع أقسام الجامعة. أما التثبيتات المنفصلة فتناسب المواقع التي تختلف بشكل كبير، أو تحتاج إلى عزل كامل لأسباب أمنية أو امتثالية، أو يجب أن تتوسع بشكل مستقل. وتستقر كثير من الجامعات على تعدد المواقع لغالبية مواقع أقسامها، وعلى التثبيتات المنفصلة لأي موقع له متطلبات مميزة فعليًا. وينبغي أن يتبع القرار العلاقة الفعلية بين المواقع، لا مجرد تفضيل عدد أقل من الأجزاء المتحركة.