سير عمل اعتماد المحتوى في دروبال للجامعات

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

يمنح سير عمل اعتماد المحتوى كل صفحة نفس المسار للوصول إلى الجمهور. تبدأ الصفحة كمسودة، وتنتظر مراجعًا معيّنًا، وتُنشر بمجرد موافقة ذلك المراجع. يتعامل دروبال مع هذا الأمر بواسطة وحدتين أساسيتين دون أي إضافات مدفوعة. يتناول هذا المقال كيفية تكامل هاتين الوحدتين معًا، وكيفية تحجيم العملية بما يتناسب مع المؤسسة، وما الذي يتغير في المواقع متعددة اللغات، وتفاصيل الإعداد التي تحدد ما إذا كانت قائمة انتظار المراجعة ستستمر في التحرك أم ستتوقف بصمت.

لماذا يحتاج النشر الجامعي إلى خطوة مراجعة

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

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

الهدف ليس إبطاء عمل المساهمين. بل السماح لمؤلف من الكلية يكتب للمرة الأولى بصياغة المحتوى بحرية، بينما يتأكد شخص مدرَّب من أن الصفحة تستوفي المعايير قبل أن يراها أي شخص خارج المؤسسة.

كيف يعمل هذا: Workflows وContent Moderation

افتراضيًا، تمتلك صفحة دروبال حالتين فقط، منشورة أو غير منشورة، وهذا لا يكفي لوصف عملية مراجعة. تُوسّع وحدتان أساسيتان هذا الأمر.

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

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

كلتا الوحدتين هما وحدتان أساسيتان، ويستحق تاريخ استقرارهما المعرفة لأنه كثيرًا ما يُنقل بشكل غير دقيق. دخلت وحدة Content Moderation إلى النواة كوحدة تجريبية في دروبال 8.2، وتبعتها وحدة Workflows في الإصدار 8.3. صُنّفت Workflows كوحدة مستقرة في الإصدار 8.4 بينما كانت Content Moderation لا تزال في مرحلة النسخة التجريبية (beta)، ووصلت Content Moderation إلى مرحلة الاستقرار في دروبال 8.5.0. وتتطلب Content Moderation دروبال 8.4 أو إصدارًا أحدث. وفي دروبال 10 و11، تُعد الوحدتان ببساطة جزءًا من النواة، ويتم تفعيلهما من صفحة Extend. يشرح توثيق Content Moderation الرسمي خطوات الإعداد.

الحالات والانتقالات والصلاحيات التي تفرضها

توجد ثلاثة مفاهيم أساسية تحت كل سير عمل في دروبال. الحالات (States) هي الأوضاع التي يمكن أن يوجد فيها المحتوى. الانتقالات (Transitions) هي الحركات المسموح بها بينها، وهي اتجاهية، فلا يمكن للصفحة أن تقفز من مسودة إلى مؤرشفة إلا إذا سمحت بذلك. المراجعات (Revisions) هي السجل الإصداري الكامن تحت ذلك. يدعم دروبال المراجعات المعلقة، مما يعني أن بإمكان المحرر إعداد نسخة جديدة من صفحة منشورة بالفعل دون أن يظهر أي من هذا العمل للعامة حتى تتم الموافقة عليه.

الصلاحيات هي ما يحوّل هذا من مخطط إلى أداة تحكم فعلية. ينشئ دروبال صلاحية منفصلة لكل انتقال، بحيث يمكن منح حق استخدام انتقال النشر (Publish) للمراجعين وحجبه عن المساهمين. وهذه الآلية الوحيدة هي سلسلة الاعتماد بأكملها.

يؤدي تفعيل Content Moderation إلى إنشاء سير عمل تحريري افتراضي (Editorial) يحتوي على مسودة (Draft) ومنشورة (Published) ومؤرشفة (Archived). ثمة تفصيلة تُوقع الكثيرين في الخطأ: لا يُنشأ سير العمل الافتراضي هذا تلقائيًا إلا إذا كان الموقع مُثبتًا من ملف التثبيت القياسي (standard). أما في ملف تثبيت مُصغّر (minimal) أو مخصص، فيجب عليك بناؤه بنفسك.

عادةً ما توسّع مجموعة الحالات الجامعية العملية قليلاً عن الوضع الافتراضي.

ثمة نتيجة لسير العمل الافتراضي تفاجئ معظم المحررين الجدد: لا يوجد زر لإلغاء النشر. فلسحب صفحة مباشرة من الموقع، عليك ضبط المراجعة المنشورة على حالة "مؤرشفة".

تحجيم سير العمل بما يناسب الجامعة

عمليًا، تُطابق الجامعة هذا مع مجموعة صغيرة من الأدوار بدلاً من مجموعة كبيرة.

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

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

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

المواقع متعددة اللغات: مراجعة كل ترجمة على حدة

أضاف دروبال 8.5 دعمًا لمراجعة الترجمات بشكل مستقل، وعلى موقع جامعي ثنائي اللغة، يُغيّر هذا شكل العملية.

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

حدِّد ملكية اللغة قبل إعداد أي شيء. قرر من يراجع أي لغة، وقرر ما ينبغي أن يراه الزوار عندما تُعتمد ترجمة ولا تُعتمد أخرى. فالمراجعة المستقلة تعني أن الصفحة يمكن أن تكون منشورة بشكل مشروع بلغة وغير موجودة بلغة أخرى، لذا تأكد من أن سلوك النسخة الاحتياطية (fallback) يتوافق مع ما تنويه.

تفاصيل الإعداد التي تُعطّل قائمة انتظار المراجعة

معظم سير عمليات الاعتماد التي تفشل لا تفشل بسبب التصميم. بل تفشل بسبب تفاصيل إعداد صغيرة تجعل قائمة الانتظار غير مرئية أو غير قابلة للاستخدام.

• لا يستطيع المراجعون رؤية ما يُفترض بهم مراجعته. صلاحيات الانتقال وحدها لا تكفي. يحتاج المراجعون أيضًا إلى صلاحية عرض آخر إصدار، وعرض أي محتوى غير منشور. بدون ذلك، تبدو قائمة المراجعة فارغة ببساطة.
• تتراكم المسودات وتُنشر معًا. مراجعات المسودة تراكمية، بحيث يُبنى كل منها على السابق بدلاً من أن تكون مستقلة. فإذا حفظ عدة أشخاص مسودات لنفس الصفحة قبل أن يراجعها أحد، فإن النشر لن يُصدر تغييرًا واحدًا فقط من تلك التغييرات. بل يُصدرها كلها دفعة واحدة، وهو أمر يسهل إغفاله في صفحة لها أكثر من مؤلف.
• لا يمكن للمحتوى القفز مباشرة إلى المراجعة. الانتقالات اتجاهية، لذا ما لم تُعرّف صراحة انتقالًا من منشورة إلى حالة المراجعة الخاصة بك، فإن المساهم الذي يُحدّث صفحة مباشرة يجب عليه حفظها كمسودة أولاً ثم تقديمها ثانيًا. ومن السهل إغفال هذا الانتقال عندما يُصمَّم سير العمل حول الصفحات الجديدة بدلاً من التعديلات على الصفحات القائمة.
• لا أحد يعرف أن الدور عليه. إذا تُرك الأمر للفحص اليدوي، يبقى المحتوى في المراجعة لأن لا أحد لاحظ وصوله. تُرسل وحدة Content Moderation Notifications رسالة بريد إلكتروني إلى دور مُختار أو إلى مؤلف المحتوى كلما انتقلت قطعة محتوى بين الحالات، وتُعدَّد من الصفحة /admin/config/workflow/notifications. أما لوحة تحكم تُدرج كل ما هو حاليًا في قائمة الانتظار فتغطي الباقي.
• لا يزال يتعين على المراجعين تسجيل الدخول. يُظهر دروبال المراجعات غير المنشورة فقط للمستخدمين الموثّقين الذين يمتلكون الصلاحيات الصحيحة، لذا فإن سير عمل يعتمد على عميد مشغول يُلقي نظرة عابرة على صفحة لن يعمل بالطريقة التي صُمم بها.

متى لا يستحق سير عمل الاعتماد العناء

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

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

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

يستحق حدّان الانتباه قبل الالتزام بهذا النظام. يُطبَّق الاعتماد التحريري فقط على الكيانات القابلة للمراجعة (revisionable)، والتي تشمل العُقد (nodes) وأنواع الكتل المخصصة ومصطلحات التصنيف، ولكن ليس كل شيء في الموقع. كما أن قرار المنصة يقع أساسًا تحت كل هذا؛ وإذا كان هذا القرار لا يزال مفتوحًا، فإن مقارنتنا بين دروبال ووردبريس للجامعات تغطي أين يناسب كل منهما.

عند إعداده بهذا الانضباط، يتوقف اعتماد المحتوى عن كونه طبقة إضافية ويصبح جزءًا من كيفية عمل المنصة. تُساهم الكليات والأقسام على نطاق واسع، وتقف مراجعة موثوقة أمام أي شيء يصل إلى الجمهور. في Drupart، يبني فريق Drupal4edu منصات دروبال لجامعات مثل جامعة سابانجي (Sabancı) وجامعة الشرق الأوسط التقنية (METU) وجامعة يلدز التقنية (Yıldız)، حيث يستند الاعتماد التحريري إلى نفس الأساس النووي الموصوف هنا. تتناول نظرتنا العامة على دروبال في التعليم بمزيد من التفصيل سبب ملاءمة هذا الأساس للتعليم العالي.

أسئلة شائعة حول اعتماد المحتوى في دروبال

آخر تحديث: 02.09.2026 08:21