استضافة Drupal: ما الذي يشغّل Drupal فعلاً

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

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

ما الذي يحتاجه Drupal فعلاً من الاستضافة؟ إصدار PHP عند الحد الأدنى لإصدارك أو فوقه، وMySQL أو MariaDB أو PostgreSQL حديث، و256 MB من ذاكرة PHP عملياً، وOPcache، ووصول صدفة لـComposer وDrush، ومهمة cron حقيقية، وذاكرة كائنات خارجية بمجرد وجود مستخدمين مسجّلي الدخول. الاستضافة المشتركة الرخيصة تسقط في ثلاثة أو أربعة من هذه دفعة واحدة.

ما الذي يتطلبه Drupal فعلاً من الخادم

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

الحد الأدنى لإصدار PHP غير قابل للتفاوض

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

وهذا أثقل مما يبدو، لأن فروع PHP نفسها تنتهي. فـصفحة الإصدارات المدعومة على php.net تحدد نهاية الدعم الأمني لـPHP 8.2 في 31 ديسمبر 2026، وللإصدار 8.3 في 31 ديسمبر 2027، وللإصدار 8.4 في 31 ديسمبر 2028. أما PHP 8.1 فقد تجاوز ذلك أصلاً. والمستضيف الذي يعلن عن “توفر PHP 8.1 و8.2” يعرض بيئة غير مرقّعة الآن أو ستصبح كذلك خلال أشهر.

والموعدان يتصادمان. فـDrupal 10 يصل إلى نهاية عمره في 9 ديسمبر 2026 ويصدر Drupal 12 في الأسبوع نفسه، بحسب جدول إصدارات النواة. وإن لم يستطع مستضيفك تقديم PHP 8.3 أو أحدث، فلن تتمكن بعد ذلك من تشغيل Drupal مدعوم. ويشرح دليلنا عن تكاليف ترحيل Drupal وخياراته ومواعيده ما يعنيه ذلك إن كنت ما زلت على الإصدار 10.

محركات قواعد البيانات وحدودها الدنيا الحقيقية

يريد Drupal 11 إصدار MariaDB 10.6 أو أحدث، أو MySQL 8.0 أو أحدث، أو PostgreSQL 16 أو أحدث، أو SQLite 3.45 أو أحدث، وفق متطلبات خادم قاعدة البيانات. أما Drupal 10 فأكثر تسامحاً مع MariaDB 10.3.7 وMySQL 5.7.8 وPostgreSQL 12 وSQLite 3.26، ولهذا بالضبط يفرض الترقّي أحياناً ترقية لقاعدة البيانات لم يكن العميل يتوقعها.

وثمة تفصيلان يُتجاوزان. فيجب أن يكون InnoDB محرك التخزين على MySQL وMariaDB، لأن Drupal يعتمد على المعاملات وعلى القفل على مستوى الصف. وعلى PostgreSQL يجب إنشاء الامتداد pg_trgm على قاعدة بيانات Drupal قبل التثبيت، وخدمة قواعد بيانات مُدارة لا تتيح تنفيذ CREATE EXTENSION غير صالحة للاستخدام.

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

الذاكرة والامتدادات وخادم الويب

الحد الأدنى الموثّق في Drupal هو 64 MB من ذاكرة PHP، وهو يعرض تحذيرات تحته. وتشير الصفحة نفسها إلى أن 128 MB أو 256 MB هي المعتاد في الإنتاج، وأن التثبيتات الغنية بالوسائط تحتاج أكثر. وعملياً اعتبر 256 MB قيمة العمل وتوقّع رفعها لسطر الأوامر، لأن العمليات الشرهة للذاكرة هي Composer وعمليات الترحيل الكبيرة، لا تقديم الصفحات.

قائمة الامتدادات غير مفاجئة وتستحق التحقق مع ذلك: PDO مع مشغّل قاعدة بيانات، وXML، وJSON، وmbstring، وcURL، وOpenSSL لاتصالات HTTPS الصادرة، وGD أو ImageMagick لاشتقاقات الصور. ويضيف Drupal 12 خوارزمية Argon2 لتجزئة كلمات المرور، وهو شيء آخر لن تجده في بناء PHP قديم جداً.

وعلى صعيد خادم الويب يدعم Drupal إصدار Apache 2.4.7 أو أحدث وNginx 1.1 أو أحدث، ولم يعد يدعم Microsoft IIS اعتباراً من Drupal 11.0.0. ويحتاج Apache إلى mod_rewrite للروابط النظيفة وإلى AllowOverride All كي يسري ملف .htaccess المرفق. وهذه النقطة الأخيرة توقع كثيرين: بعض قواعد الحماية في Drupal موجودة في .htaccess فقط، لذا على أي نشر على Nginx أن يعيد إنتاجها يدوياً في إعدادات الخادم. إنها خطوة روتينية تُتجاوز روتينياً، وهي من أول ما نبحث عنه في تدقيق أمان الخادم.

لماذا تفشل الاستضافة المشتركة مع Drupal

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

بلا صدفة أوامر لا Composer ولا Drush

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

ولا تستطيع لوحة تحكم فيها مدير ملفات فعل ذلك. ولا عميل FTP. وبلا SSH تفقد أيضاً Drush، وهو ما تُنفَّذ به فعلياً إعادة بناء الذاكرة المؤقتة واستيراد الإعدادات وتحديثات قاعدة البيانات وإعادة تعيين كلمات المرور. والموقع الذي لا تستطيع تشغيل drush cr عليه هو موقع تتحول فيه كل خطوة تعافٍ إلى تذكرة دعم.

الحدود التي لا تراها، فضلاً عن تغييرها

يمنحك الحساب المشترك قيمة memory_limit يحددها شخص آخر، غالباً 128 MB وأحياناً أقل، دون أي سبيل لرفعها من أجل عملية الترحيل الوحيدة التي تحتاج 512 MB.

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

ثم يأتي ما هو غائب تماماً: لا Redis، ولا Memcached، ولا تحكم في مدير عمليات PHP، ولا سبيل لتشغيل عامل طوابير طويل الأمد.

cron لا يعمل حقاً أبداً

تعمل وحدة Automated Cron في Drupal كل ثلاث ساعات افتراضياً ويشغّلها زوار الموقع. وعلى موقع مزدحم يعني ذلك أن زائراً يدفع بين حين وآخر ثمن فهرسة البحث من زمن تحميل صفحته. وعلى موقع هادئ يعني أن cron لا يعمل عملياً، فيتقادم فهرس البحث، ولا تُقلَّم جداول السجلات أبداً، ولا يُتحقق أبداً من تحديثات الأمان المتاحة.

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

طبقات التخزين المؤقت وأيها يصيب زائرك

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

OPcache تقع تحت Drupal بالكامل

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

Internal Page Cache وDynamic Page Cache

Internal Page Cache وحدة من النواة، مفعّلة افتراضياً، وتخدم المستخدمين المجهولين فقط. تفترض أن كل زائر مجهول يرى الصفحة نفسها، فتخزّن الاستجابة كاملة عند أول طلب وتعيد استخدامها. وعلى موقع تسويقي بلا تخصيص، هذه هي الطبقة التي تؤدي العمل كله تقريباً.

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

BigPipe وذاكرة العرض المؤقتة

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

وBigPipe يتولى ما تبقى. فهو في النواة منذ Drupal 8.1، ومستقر منذ 8.3، وضمن ملف التثبيت القياسي منذ 8.5. وبدل انتظار حل كل عنصر نائب، يرسل الصفحة القابلة للتخزين فوراً ثم يبث الأجزاء المخصصة بعدها. لا يحتاج إعداداً، وهو يفيد المستخدمين المسجّلين أكثر بكثير من المجهولين.

وهكذا يصيب الزائر المجهول على موقع حسن الإعداد Internal Page Cache أو شبكة التوصيل أمامها، ولا يلمس معظم ما سبق أبداً. أما المحرر المسجّل فيصيب مع كل طلب Dynamic Page Cache وذاكرة العرض وBigPipe، ولهذا تكلّف الزيارات المسجّلة أكثر بكثير.

ذاكرة الكائنات الخارجية

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

وتنقل وحدة Redis واجهات التخزين المؤقت والأقفال وflood والطوابير إلى Redis أو إلى مخزن متوافق مثل Valkey، عبر امتداد PhpRedis أو امتداد Relay أو مكتبة Predis المكتوبة بلغة PHP خالصة. وMemcached هو البديل المكافئ. وعلى موقع صغير بزيارات مجهولة لا يغير هذا كثيراً. أما على موقع فيه مستخدمون مسجّلون فهو عادة أكبر تحسين متاح، لأنه يزيح أعلى أحمال الكتابة ضجيجاً عن قاعدة البيانات ويجعل القفل رخيصاً.

الوكيل العكسي وشبكة التوصيل أمام Drupal

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

وسوم التخزين المؤقت هي ما يجعل شبكة التوصيل آمنة

جواب Drupal هو وسوم التخزين المؤقت. وسوم التخزين المؤقت تصف تبعيات البيانات، وتُكتب كسلاسل نصية مثل node:5 أو user:3 أو node_list. وكل عنصر مخزّن يسجل الوسوم التي يعتمد عليها، فتحرير العقدة 5 يُبطل كل جزء وصفحة وعرض مخزّن أشار إليها، أينما ظهرت.

والجزء المهم أن Drupal يستطيع نشر تلك الوسوم إلى الخارج. فالوحدات المساهَم بها تصدرها كترويسة Surrogate-Key لـFastly أو ترويسة Cache-Tag لـCloudflare، فتُفرغ الشبكة حينها بحسب الوسم عندما يخبرها Drupal. وهذا يحوّل شبكة التوصيل من مقامرة على الزمن إلى ذاكرة مؤقتة تقودها الأحداث: يمكنك ضبط مدة صلاحية طويلة، لأن التحرير يفرّغ الروابط المتأثرة بالضبط خلال ثوانٍ.

وانتبه لميزانية الترويسة. فـتوثيق Cloudflare عن الإفراغ بحسب وسم التخزين يحدّ ترويسة Cache-Tag المجمّعة بـ16 KB بعد اسم الحقل، أي نحو 1,000 وسم فريد، بحد أقصى 1,024 حرفاً للوسم الواحد في نداء API و100 وسم لكل عملية إفراغ من لوحة التحكم. وعرض Drupal الذي يسرد كيانات كثيرة قد يولّد وسوماً أكثر من ذلك بكثير، فصفحة تسرد كل شيء ستتجاوز حد الترويسة بصمت ما لم تُضبط الوحدة على تقصير الوسوم أو تجزئتها.

اختيار استضافة Drupal: أربع فئات بصراحة

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

الاستضافة المشتركة

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

VPS أو نسخة سحابية غير مُدارة

نحو 20 إلى 120 GBP شهرياً تشتري جهازاً بصلاحية root كاملة، وهو ما يناسب الغالبية العظمى من مواقع Drupal. أنت تختار إصدار PHP، وتحدد حجم OPcache، وتثبّت Redis، وتضبط crontab، وتُعدّ Nginx كما ينبغي. وما لا تحصل عليه هو من يفعل ذلك، ويرقّعه، ويراقبه، ويستعيده في الثانية فجراً. هذه الفئة صحيحة حين يكون لديك مطور أو وكالة بعقد شهري، والعقد هو التكلفة الحقيقية لا النسخة.

منصات Drupal المُدارة المتخصصة

تبدأ استضافة Drupal المُدارة عند نحو 40 GBP شهرياً لموقع صغير وترتفع سريعاً مع الزيارات والبيئات ومستوى الدعم. وما تشتريه بيئة مفروضة صحيحة أصلاً، ومعها نشر قائم على Git، وبيئات اختبار، ونسخ احتياطية، ومن يفهم Drupal على الطرف الآخر من الخط. إنها قيمة جيدة حين يكون البديل لا أحد، وقيمة سيئة حين تدفع أسعار منصة لموقع تعريفي يتلقى 4,000 زيارة في الشهر.

بنية تحتية مخصصة بالكامل

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

النشر: لا تحرر الملفات على الخادم

لأن Composer يحلّ شجرة التبعيات كاملة، فإن الشيفرة على الخادم ناتج لا مساحة عمل. وتحرير ملف وحدة في مكانه يعني أن composer update التالي سيكتب فوقه، ويعني أن شيفرة الإنتاج لديك لم تعد تطابق شيئاً في Git.

عملية إصدار سليمة تبني الناتج في مكان آخر. شغّل composer install من ملف composer.lock المُودَع داخل التكامل المستمر، كي يكون البناء قابلاً للتكرار وكي لا يحتاج خادم الإنتاج أبداً إلى Composer ولا إلى ذاكرة PHP لحل التبعيات ولا إلى صلاحية كتابة على vendor. ثم اشحن الناتج، ونفّذ تحديثات قاعدة البيانات، واستورد الإعدادات، وأعد بناء الذواكر المؤقتة. والتراجع يعني الإشارة إلى الناتج السابق.

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

أين تقع مزامنة الإعدادات

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

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

الملفات والوسائط والنسخ الاحتياطية

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

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

نقل الوسائط إلى تخزين الكائنات

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

اختبار الاستعادة يثبت ما لا تثبته النسخة الاحتياطية

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

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

تحديد حجم استضافة Drupal بشكل صحيح

مشاهدات الصفحات وحدة قياس خاطئة. فموقع فيه 200,000 مشاهدة مجهولة شهرياً خلف شبكة توصيل قد يكون مرتاحاً على نسخة صغيرة، بينما موقع فيه 8,000 مشاهدة قد يتعثر إن كان معظمها لمستخدمين مسجّلين.

الزيارات المسجّلة هي المحرك الحقيقي

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

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

العروض والتصنيفات وعمل الطوابير

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

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

اتخاذ القرار الصحيح

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

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

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

ما الحد الأدنى لمتطلبات الخادم لـDrupal 11؟ PHP 8.3 أو أحدث، وكقاعدة بيانات MariaDB 10.6 أو MySQL 8.0 أو PostgreSQL 16 أو SQLite 3.45. وعلى جانب خادم الويب Apache 2.4.7 أو Nginx 1.1 وأحدث، مع عدم دعم Microsoft IIS اعتباراً من Drupal 11.0.0. ويحذر Drupal تحت 64 MB من ذاكرة PHP، لكن 256 MB هو الرقم الواقعي في الإنتاج.

هل يمكن تشغيل Drupal على استضافة مشتركة؟ سيُثبَّت وسيقدم صفحات، لكن الاستضافة المشتركة تسقط عادة في ثلاثة أو أربعة متطلبات دفعة واحدة: لا وصول صدفة لـComposer أو Drush، وحد ذاكرة PHP لا تستطيع رفعه، ولا Redis ولا Memcached، وcron لا ينطلق إلا حين يصادف أن يحمّل زائر صفحة. هذه الظروف هي ما ينتج سمعة البطء عن Drupal.

كم ينبغي أن تكلف استضافة Drupal؟ موقع Drupal صغير على نسخة غير مُدارة مضبوطة بشكل صحيح يقع عادة بين 20 و120 GBP شهرياً قبل أن يديره أحد. ومنصات Drupal المُدارة تبدأ غالباً قرب 40 GBP وترتفع إلى المئات مع الزيارات والبيئات. والبنية التحتية المخصصة تبدأ في أن تصبح منطقية فوق نحو 400 GBP. وأرخص فئة نادراً ما تكون أرخص نتيجة.

هل يحتاج Drupal إلى Redis؟ ليس لموقع صغير بزيارات مجهولة، حيث تكفي ذاكرة الصفحات الداخلية وقاعدة البيانات. لكن بمجرد وجود مستخدمين مسجّلين أو محررين أو منطقة أعضاء، فإن ذاكرة كائنات خارجية مثل Redis أو Memcached تنقل قراءات التخزين المؤقت والأقفال والطوابير خارج قاعدة البيانات، وهي عادة أكبر تحسين متاح مقابل المال.

هل شبكة التوصيل آمنة أمام موقع Drupal ديناميكي؟ نعم، شرط أن تبطل الصلاحية بحسب وسم التخزين لا بحسب الزمن. فـDrupal يسجل وسوماً مثل node:5 لكل ما تعتمد عليه الاستجابة، والوحدات تترجمها إلى ترويسات Cache-Tag أو Surrogate-Key كي تفرّغ الشبكة الصفحات التي مسّها التحرير بالضبط. وبلا إبطال بحسب الوسم فأنت تختار بين صفحات متقادمة وذاكرة مؤقتة لا تنفع أبداً.