دعم Drupal: ما الذي يجب أن يغطيه عقد الصيانة

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

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

أمران يميزان Drupal عن صيانة المواقع العامة. تنبيهاته الأمنية تصدر وفق جدول منشور، فنافذة تعرضك قابلة للقياس ويمكن كتابتها في العقد. وموقع Drupal تجميعة من وحدات مساهَم بها لكل منها صيانة مستقلة، فلا بد أن يتابع أحدهم نيابة عنك هدف ترقية متحركاً.

ما الذي يجب أن يغطيه عقد دعم Drupal؟ مراقبة التنبيهات الأمنية التي تنطبق على مجموعة وحداتك بالضبط، وتطبيق تحديثات النواة والوحدات المساهَم بها ضمن دورة محددة عبر بيئة تجريبية، والتحقق من أن النسخ الاحتياطية تُستعاد فعلاً، ومراقبة الإتاحة وأخطاء التطبيق، وميزانية تغييرات مسماة للأعمال الصغيرة. في المملكة المتحدة يبدأ ذلك من نحو £250 شهرياً لموقع تعريفي بسيط ويصل إلى £2,000 أو أكثر لموقع معقد. تحت هذا الحد أنت تشتري مراقبة، لا دعماً.

ما الذي يعنيه دعم Drupal فعلياً شهراً بعد شهر

اطلب عرض سعر من ثلاث وكالات وستصلك ثلاث باقات باسم Essential وBusiness وEnterprise، كل واحدة قائمة نقاط من الأسماء. الأسماء ليست العمل. العمل مجموعة مهام متكررة تحدث وفق جدول أو لا تحدث إطلاقاً، والتمرين المفيد هو أن تجعل المورد يصف كل واحدة منها كنشاط، بمسؤول وبتواتر.

عددها ثمانية. مراقبة التنبيهات الأمنية وتطبيق الترقيعات. تحديثات النواة والوحدات المساهَم بها. ترقية الاعتماديات وإصدارات المنصة. التحقق من النسخ الاحتياطية واختبار الاستعادة. مراقبة الإتاحة وأخطاء التطبيق. فحوص انحدار الأداء. الدعم التحريري. وميزانية تغييرات للأعمال الصغيرة التي تصل دائماً.

العقد الذي يذكر الثمانية ليس جيداً تلقائياً، لكن العقد الذي يذكر أربعة ناقص بوضوح، والأربعة التي تسقط هي نفسها تقريباً في كل مرة: اختبار الاستعادة، وانحدار الأداء، وترقيات المنصة، وميزانية التغييرات. هذه هي المكلفة، ولذلك تختفي.

لماذا تخفي أسماء الباقات العمل

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

استبدل كل عبارة بثلاث حقائق: النشاط، وتواتره، والدور المسمى الذي ينفذه. معظم صفحات الباقات تتفكك تحت هذه المعاملة، والتي تصمد منها تشير إلى الموردين الذين يستحقون الحديث.

نافذة الترقيع هي المنتج كله

ينشر Drupal إصدارات الأمان وفق جدول زمني، وهو أمر غير معتاد ومفيد للغاية. إصدارات أمان النواة تخرج في نافذة الأربعاء الثالث من الشهر ، بدءاً من 1200 America/New York، أي 1600 أو 1700 UTC حسب الفصل. وللمشاريع المساهَم بها نافذة إصدار أمني كل أربعاء ، فتصل تنبيهات الوحدات المساهَم بها أكثر بكثير من تنبيهات النواة، وعلى دفعات.

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

كل بند آخر في عقد الدعم زينة بجانب عدد الساعات في تلك الفجوة. لذا فالسؤال الأول لأي مورد محتمل حساب، لا فلسفة. في الأربعاء الثالث من الشهر القادم، في أي ساعة سيقرأ إنسان التنبيه، ومتى سيكون الترقيع على الهواء؟ عبارة “ضمن اتفاقية مستوى الخدمة المعتادة لدينا” ليست جواباً على هذا السؤال.

كيف يسجل Drupal درجة الخطر، وماذا ينبغي أن يفعل ذلك بعقدك

كل تنبيه من Drupal يحمل رقماً، وهذا الرقم أقل أدوات المنصة استخداماً في صياغة البنود. يقيّم Drupal الثغرات باستخدام نظام NIST لتسجيل سوء الاستخدام، NISTIR 7864 ، منتجاً درجة من 0 إلى 25 عبر ستة مقاييس: تعقيد الوصول، والاستيثاق، وأثر السرية، وأثر السلامة، وتوافر أداة استغلال، وانتشار الهدف.

تنعكس الدرجة على خمس تسميات منشورة. الدرجة من 0 إلى 4 هي Not Critical، ومن 5 إلى 9 هي Less Critical، ومن 10 إلى 14 هي Moderately Critical، ومن 15 إلى 19 هي Critical، ومن 20 إلى 25 هي Highly Critical. هذه النطاقات علنية وثابتة وغير قابلة للتأويل من أي من الطرفين.

وهذا ما يجعلها العمود الفقري الطبيعي لاتفاقية مستوى خدمة الدعم، ومع ذلك لا يكاد أحد يستخدمها. فبدلاً من اختراع تعريفات خاصة للخطورة يستطيع المورد الجدل حولها لاحقاً، اكتب التزام الاستجابة مقابل درجة Drupal مباشرة: Highly Critical تُرقّع خلال عدد ساعات محدد يشمل خارج أوقات العمل، وCritical خلال يوم عمل واحد، وModerately Critical في الدورة المجدولة التالية، وما عدا ذلك يُجمّع. لا يستطيع أي طرف إعادة فتح النقاش حول معنى “عاجل”، لأن طرفاً ثالثاً حسمه سلفاً.

Highly Critical حدث تشغيلي مختلف

إصدارات النواة من فئة Highly Critical نادرة، وDrupal يتعامل معها بشكل مختلف. ينشر فريق الأمان مسبقاً إعلان خدمة عامة كي يتمكن مالكو المواقع من ترتيب التغطية. وقد فعل PSA-2026-05-18 ذلك بالضبط، محذراً في 18 مايو 2026 من إصدار نواة بالغ الخطورة مقرر ليوم الأربعاء 20 مايو ويطال جميع الفروع المدعومة.

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

وهناك أيضاً إجراء تخفيف يستحق المعرفة. Drupal Steward جدار حماية لتطبيقات الويب مدفوع وموزع عالمياً تديره Drupal Association وفريق الأمان، ويوفر ترقيعاً افتراضياً على مستوى الشبكة لثغرات النواة البالغة الخطورة، فيبقى الموقع محمياً بينما يُختبر التحديث. الأسعار منشورة بالدولار الأمريكي وتتدرج مع حركة الزوار: أقل من 20 دولاراً شهرياً لموقع يخدم نحو 1 مليون طلب HTTP، وأقل من 100 دولار شهرياً فوق 10 ملايين. هو يشتري وقتاً لا مناعة، والعقد الجيد يقول من يدفع ثمنه.

ما الذي لا تغطيه سياسة التنبيهات الأمنية

ثلاثة استثناءات في سياسة عملية التنبيهات الأمنية والصلاحيات تغير ما يجب أن يفعله عقد الصيانة، ومعظم عقود الدعم صامتة عن الثلاثة جميعاً.

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

ثم يأتي ما يفاجئ الناس: لا تصدر تنبيهات للمكتبات الخارجية، حتى حين يفرض عليك مشروع مساهَم به تثبيت إحداها. مكتبة JavaScript أو PHP مسحوبة كاعتمادية هي مشكلتك أنت، تتابعها بنفسك، ولن تظهر في تغذية Drupal.

يمكن سحب التغطية أيضاً

التغطية الأمنية ليست دائمة. فقد سحب PSA-2026-07-22 التغطية عن وحدة QA Accounts بحجة أنها تقدم سهولة الاستخدام على الأمان وأنها مخصصة فقط للمواقع غير القابلة للوصول من الإنترنت.

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

ترقية الاعتماديات والمنصة عمل دعم

أكثر البنود استبعاداً من عقود دعم Drupal هو البند الذي يقرر في النهاية ما إذا كان الموقع سينجو. متطلبات منصة Drupal تتحرك، وتتحرك بخطوات تحتاج إلى تغيير الاستضافة لا إلى composer update.

في PHP، يتطلب Drupal 10 إصدار PHP 8.1 على الأقل ، بينما يفرض Drupal 11 إصدار PHP 8.3 حداً أدنى منذ 11.1. ووصل دعم PHP 8.5 في Drupal 11.3، وDrupal 12.0 يدعم PHP 8.5 حصراً. هذه التفصيلة الأخيرة أثقل مما تبدو: الموقع الجالس اليوم مرتاحاً على PHP 8.1 يبعد نقلتي منصة إجباريتين عن Drupal 12.

ومتطلبات قواعد البيانات تحركت بالقدر نفسه. يحتاج Drupal 11 إلى MySQL 8.0 أو أحدث، أو MariaDB 10.6 أو أحدث، أو PostgreSQL 16 أو أحدث، أو SQLite 3.45 أو أحدث. وكان Drupal 10 يقبل MySQL 5.7.8 وMariaDB 10.3.7 وPostgreSQL 12. المستضيف المُدار الذي ما زال يقدم MySQL 5.7 عائق على مسار الترقية لا تفصيلة، وملاحظتنا عن ما يشغل Drupal جيداً فعلاً تشرح إلى أين تنتقل.

نهاية عمر Drupal 10 مشكلة عقد بالفعل

يبلغ Drupal 10 نهاية عمره في 9 ديسمبر 2026 ، ويصدر Drupal 12 في الأسبوع نفسه، ابتداءً من 7 ديسمبر 2026. وينتهي الدعم الأمني لفرعي 11.3.x و10.6.x عند النقطة ذاتها. وحتى سبتمبر 2026 فإن الفروع التي تتلقى إصدارات أمنية هي 11.4.x و11.3.x و10.6.x.

قراءةً مقابل التقويم، هذه نحو ثلاثة أشهر. وأي موقع على Drupal 10 بلا خطة ترقية مسعّرة في سبتمبر 2026 سيقضي ديسمبر إما دافعاً علاوة استعجال وإما مشغلاً بلا دعم، والخيار الثاني قرار ينبغي أن يتخذه أحدهم عمداً لا بالانجراف.

العقد الذي يستحق أتعابه كان يجب أن ينتج أربعة أشياء حتى الآن: تقرير حالة ترقية محدثاً، وفحصاً للشيفرة المهجورة في الوحدات المخصصة والقالب، وفحص جاهزية لكل وحدة مساهَم بها مقابل Drupal 11 و12، وتقديراً مكتوباً. فإن لم ينتج موردك أياً منها حتى اليوم، فتلك هي النتيجة. وتفصيلنا عن تكاليف ترحيل Drupal وخياراته ومواعيده يبين ما ينطوي عليه العمل، والتخطيط نفسه موجود داخل مشاريع تطوير المواقع لدينا.

النسخ الاحتياطية لا تساوي شيئاً حتى تُختبر الاستعادة

يكاد كل عقد دعم Drupal يعد بنسخ احتياطية. وقليل جداً منها يعد باستعادة، وهذا الفارق هو قيمة البند كله. تقول NCSC ذلك بوضوح في دليلها للمؤسسات الصغيرة: بعد أن تأخذ نسختك الاحتياطية ، عليك أن تعرف كيف تستعيدها وأن تتحقق من أنها تحوي كل ما يهم.

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

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

مراقبة الإتاحة والأخطاء، وما تقيسه الإتاحة حقاً

هناك فجوة واسعة بين خادم يعمل وموقع يعمل، وDrupal يقع في وسطها تماماً. خطأ PHP قاتل، أو حد ذاكرة مستنفد، أو اتصال فاشل بقاعدة البيانات، أو إعادة بناء ذاكرة مخبأة معطلة، كلها تنتج صفحة يقرأها الفحص الساذج نجاحاً، أو خطأ 500 بسيطاً لا يراقبه أحد.

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

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

قراءة نقدية لاتفاقية مستوى خدمة الدعم في Drupal

معظم اتفاقيات مستوى الخدمة مكتوبة لتُوقَّع لا لتُستخدم، وهي تُوقَّع لأنها تُقرأ بسرعة. ثلاثة بنود تحمل الثقل كله تقريباً، وقراءتها بعناية تستغرق عشر دقائق.

زمن الاستجابة ليس زمن الحل

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

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

تعريفات الخطورة تحسم كل شيء

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

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

ساعات التغطية ليست ساعات العمل

“ساعات العمل” و"التغطية" تعنيان أمرين مختلفين ويُستعملان أحدهما مكان الآخر كثيراً. التغطية هي المدة التي تعمل فيها الساعة ويكون فيها أحدهم ملزماً بالتصرف. فإذا كانت التغطية من 09:00 إلى 17:30 في أيام العمل، فإن تنبيهاً يُنشر في 1700 UTC يوم أربعاء من ديسمبر يُلتقط في صباح اليوم التالي في أفضل الأحوال.

وبالنسبة إلى Drupal تحديداً، لاحظ أن نافذة أمان النواة تفتح في 1600 أو 1700 UTC. المورد البريطاني الذي تنتهي تغطيته في 17:30 يقف هيكلياً على حافتها، لذا يجب تسمية ترتيبات خارج أوقات العمل لتنبيهات Highly Critical على حدة وتسعيرها.

ما الذي يُعد حادثاً وما المستبعد

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

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

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

نماذج العقود الثلاثة، مقارنة بأمانة

يكاد كل ترتيب دعم لـ Drupal يأخذ واحداً من ثلاثة أشكال، وكل شكل جواب معقول لحالة مختلفة. والخطأ هو شراء شكل مع توقع سلوك شكل آخر.

ساعات ثابتة في الشهر

تشتري كتلة ساعات، لنقل 8 أو 16، ويطبقها المورد على ما تطلبه. الأمر شفاف، وسهل المقارنة بين العروض، ويناسب مؤسسة لديها تدفق ثابت من التغييرات الصغيرة وشخص داخلي قادر على ترتيب أولوياتها.

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

إصلاحات غير محدودة مع تسعير التغييرات

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

ضعفه هو الحد الفاصل. “الإصلاح الصغير” غير معرَّف حتى يحتاجه أحد، والحد يتحرك بحسب سير الشهر. أصرّ على تعريف مكتوب، ويفضل أن يكون حداً زمنياً مثل كل ما يقل عن 30 دقيقة، وعلى تقرير شهري يبين ما جرى استيعابه.

الوقت والمواد الصرفة

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

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

مشكلة الحوافز في الدعم غير المحسوب

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

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

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

كيف يبدو العمل الجيد تشغيلياً

ثلاث ممارسات تقنية تفصل مورد Drupal القادر على دعم موقعك بأمان عن المرتجل. لا شيء منها غريب، والسؤال عن الثلاث جميعاً سهل.

Composer أو لا شيء

وثائق Drupal نفسها صريحة بشأن خلط طرق التحديث، وتحذر من أن المواقع قد تواجه مشكلات تحديث حرجة إذا مُزجت تحديثات Composer بمقاربات أخرى، ومن أن Composer متى أدار وحدة وجب أن يدير النواة أيضاً. المورد الذي ما زال يرفع مجلدات الوحدات عبر FTP سيحذف في النهاية مجلد vendor اعتمدت عليه وحدة مساهَم بها.

اسأل هل composer.json وcomposer.lock في نظام إدارة الإصدارات، وهل يعمل Composer على الإنتاج أم يُنشر الناتج المبني. كلا الجوابين قد يكون صحيحاً. أما ألا يكون هناك جواب فلا يمكن أن يكون صحيحاً.

بيئة تجريبية تطابق الإنتاج

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

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

الإعدادات في نظام إدارة الإصدارات

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

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

إن عجزوا عن وصف النشر، فذلك هو الجواب

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

بند إنهاء التعاقد الذي لا يقرأه أحد

ستغير المورد في مرحلة ما، والبند الذي يحكم تلك اللحظة يُكتب بينما الجميع ودودون ويُقرأ حين لم يعد أحد كذلك. ينبغي أن يقول أربعة أمور بوضوح.

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

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

Drupal 7: نهاية العمر والدعم الممتد والفجوة بينهما

انتهى الدعم الأمني لـ Drupal 7 في 5 يناير 2025 . توقف المجتمع عن إنتاج الترقيعات، وتوقفت معه صيانة منظومة الوحدات المساهَم بها الضخمة التي جعلت Drupal 7 مفيداً.

تدير Drupal Association برنامج Extended Security Support Provider Program، وHeroDevs وTag1 Consulting هما الموردان المعتمدان ضمنه. وشراء ذلك الدعم قرار مشروع لمؤسسة لا تستطيع الترحيل هذا العام فعلاً، وهو أفضل من لا شيء بفارق ملموس.

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

إن كنت على Drupal 7 في سبتمبر 2026، فالنصيحة الصادقة أن تنفق المال على الترحيل لا على الإيجار. ودليلنا لعام 2026 لتطوير الويب بـ Drupal يغطي المنصة كما هي، والتفصيل الأعمق لعملية التنبيهات في ملاحظتنا عن أمان Drupal والتنبيهات والمخاطر الحقيقية .

الدعم التحريري وميزانية التغييرات

بندان يُستبعدان من عقود الدعم لأن حدهما صعب، وهما بالضبط ما يلاحظه العملاء.

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

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

كم يكلف دعم Drupal في المملكة المتحدة

الأرقام أدناه تقديراتنا الداخلية لعام 2026، مبنية على عمل الوكالات البريطانية لا على مسح منشور، وهي تفترض مورداً ينفذ الأنشطة الثمانية الموصوفة أعلاه لا اشتراك مراقبة معلقاً به بريد دعم.

نثراً: الموقع التعريفي الصغير يقع عند £250 إلى £600 شهرياً تقريباً، وهو ما يشتري مراقبة التنبيهات ودورة ترقيع شهرية والتحقق من النسخ الاحتياطية وساعة أو ساعتين من التغييرات. والموقع المتوسط ذو التكاملات يدور حول £700 إلى £1,800، لأن كل تكامل يضيف سطح انحدار يجب اختباره بعد كل تحديث نواة. والموقع المعقد أو المتعدد اللغات بوحدات مخصصة يبدأ قرب £2,000 ويبلغ £6,000 أو أكثر.

أما ترتيبات المراقبة فقط، حيث يراقب المورد التنبيهات ويخبرك بما ينطبق دون أن ينشر، فتقع أدنى، عند نحو £250 إلى £450 شهرياً. ضع هذه النطاقات مقابل الأجور اليومية للوكالات البريطانية البالغة £600 إلى £900، وعقد £1,500 يشتري ما يقارب يومي مهندس. وتفصيل الأجور في ملاحظتنا عن أجور مطوري Drupal ومهاراتهم وفحصهم ، والصورة الأوسع للميزانية في تكلفة صيانة البرمجيات .

ما الذي ينقل موقعاً من نطاق إلى الذي يليه

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

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

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

أسئلة تطرحها على مورد محتمل

ستة أسئلة، والإجابات التي ينبغي أن تقلقك.

على أي إصدار من Drupal ومن PHP يعمل موقعنا الآن، وما مسار الترقية؟ الجواب الذي يستلزم منهم الذهاب للتحقق مقبول. أما الذي يصل بعد أسبوع فلا. كيف تعرفون أن تنبيهاً أمنياً ينطبق علينا؟ عبارة “نتابع drupal.org” ضعيفة؛ جرد وحدات لكل موقع هو الجواب المطلوب.

اشرح لي عملية النشر لديكم. التردد هنا أقوى إشارة سلبية في المحادثة كلها. متى استعدتم هذا الموقع من نسخة احتياطية آخر مرة؟ عبارة “نأخذ نسخاً احتياطية يومية” ليست رداً على هذا السؤال. ما المستبعد من العقد، وكيف تقررون إن كان الأمر عطلاً أم تغييراً؟ وأخيراً: إن رحلنا، ماذا نستلم وبأي سرعة؟

ماذا يحدث حين لا يوجد عقد

هذه متتالية أكثر منها تحذيراً، وتسير بالوتيرة نفسها تقريباً على كل موقع Drupal بلا دعم.

في الأشهر الأولى لا يحدث شيء، وهذه هي المشكلة، لأنها تعلّم الجميع أن لا شيء يحتاج أن يحدث. وفي مكان ما بين الشهر السادس والشهر الثاني عشر يتجاوز تراكم التحديثات النقطة التي تكف عندها التحديثات عن كونها آمنة فرادى، لأن وحدة صارت تحتاج نواة أحدث، تحتاج PHP أحدث، لا يوفره المستضيف. تطبيق ترقيع واحد صار مشروعاً.

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

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

ضبط النطاق قبل التوقيع

الغاية من كل هذا ليست أن تفقد ثقتك بالموردين. الغاية أن تجعل المقارنة بين عرضين ذات معنى، لأن معظم عروض دعم Drupal اليوم غير قابلة للمقارنة بحكم تصميمها: كلمات مختلفة، واستثناءات مختلفة، وبلا تعريف مشترك لما هو العمل الشهري.

خذ الأنشطة الثمانية، ونطاقات خطر Drupal، ونماذج العقود الثلاثة، والأسئلة الستة، وضعها مقابل ما على مكتبك. وما يصمد أمام ذلك عرض حقيقي.

تدعم Mecanik مواقع Drupal ضمن عملنا في تطوير المواقع وتطوير البرمجيات ، والارتباط الأول عادةً جرد لا إصلاح، لأن معظم المواقع التي تصلنا لا تستطيع تحديد أي وحداتها ما زالت مشمولة بـتغذية التنبيهات الأمنية .

الأسئلة الشائعة

ما الذي يجب أن يتضمنه عقد دعم Drupal؟ ثمانية أنشطة: مراقبة التنبيهات الأمنية مقابل مجموعة وحداتك بالضبط، وتحديثات النواة والوحدات المساهَم بها ضمن دورة محددة، وترقية الاعتماديات ومنصة PHP، والتحقق من النسخ الاحتياطية مع استعادات مختبرة، ومراقبة الإتاحة وأخطاء التطبيق، وفحوص انحدار الأداء، والدعم التحريري، وميزانية تغييرات مسماة بالساعات. العقد الذي يذكر أربعة فقط ناقص، والأربعة الغائبة عادةً هي اختبار الاستعادة وفحوص الأداء وترقيات المنصة وميزانية التغييرات.

كم يكلف دعم Drupal شهرياً في المملكة المتحدة؟ كتقدير داخلي لعام 2026، الموقع التعريفي الصغير يكلف نحو £250 إلى £600 شهرياً، والموقع المتوسط بتكامل أو اثنين £700 إلى £1,800، والموقع المعقد المتعدد اللغات بوحدات مخصصة £2,000 إلى £6,000. وترتيبات المراقبة فقط تقع عند نحو £250 إلى £450. ومقابل الأجور اليومية للوكالات البريطانية البالغة £600 إلى £900، فإن عقداً بقيمة £1,500 يشتري نحو يومي مهندس.

متى يصدر Drupal ترقيعات الأمان؟ إصدارات أمان نواة Drupal تخرج في نافذة الأربعاء الثالث من الشهر، بدءاً من 1200 America/New York، أي 1600 أو 1700 UTC حسب الفصل. وللمشاريع المساهَم بها نافذة إصدار أمني كل أربعاء. وتسبق إصدارات النواة البالغة الخطورة إعلانات خدمة عامة كي يرتب مالكو المواقع التغطية مسبقاً.

هل الدعم الممتد لـ Drupal 7 يعادل كونك آمناً؟ لا. انتهى الدعم الأمني لـ Drupal 7 في 5 يناير 2025، وتعتمد Drupal Association شركتي HeroDevs وTag1 Consulting ضمن برنامج Extended Security Support Provider Program. هؤلاء الموردون يرقّعون ما يغطونه، وفق جدولهم هم، لمجموعة وحدات متفق عليها. وهذا لا يعيد عملية التنبيهات العلنية، ولا يغطي كل وحدة مساهَم بها ثبّتها، ولا يمتد إلى المكتبات الخارجية.

متى يبلغ Drupal 10 نهاية عمره؟ يبلغ Drupal 10 نهاية عمره في 9 ديسمبر 2026، في الأسبوع نفسه الذي يصدر فيه Drupal 12، ابتداءً من 7 ديسمبر 2026. وينتهي الدعم الأمني لفرعي 11.3.x و10.6.x في النقطة ذاتها. وDrupal 12 يدعم PHP 8.5 حصراً، فالمواقع على إصدارات PHP الأقدم تحتاج تغيير استضافة قبل الترقية لا بعدها.