في البداية اعرفكم بنفسي انا مستخدم لدروبال 6 وبعدها 7 ولي مساهمات في دروبال 8 و 9 حتى 11 بمعنى اني اعي نظام دروبال واعرف بعض الامور الخافية عن المستخدم الجديد لاني كنت من اكثر المعجبين بنظام دروبال ومازلت لكن لي تحفظات على الاصدار 8 وما بعدها وانتقاللها الى اطار Symfony كطرف ثالث وزيادة استهلاكها للموارد وابتعادها عن فئة المواقع الصغيره والمتوسطه …
- قصة نظام backdrop cms
- هل قلة فريق مشروع باك دروب يعتبر عيباً؟
- الاختلاف التقني بين دروبال 7 وباك دروب
- تضمين الوحدات المطلوبة في نواة باك دروب
- ميزة مدمج Project Installer في النواة
- ميزة تحديث النظام من لوحة التحكم مباشرة
- مشاكل واجهتني بعد الانتقال (وكيف حللتها)
- لماذا لم أختر ووردبريس كبديل لباك دروب؟
- لماذا استخدمت سيرفراً اقتصادياً (VPS) بدلاً من استضافة مشتركة؟
- ماذا عن استخدام كلوود فلير (Cloudflare)؟ هل ينقذ ووردبريس؟
- مقارنة الأداء: حتى في أبسط عمليات البحث الافتراضية؟
من اعجب الامور اللي حصلت في دروبال انه بدل تقليل استهلاك دروبال 7 للموارد وتنظيف قل النظام من الاكواد اللي ورثتها من اصدارات قديمه تم في الاصدار 8 رفع استهلاكها للموارد حتى ان اغلب الاستضافات المشتركه ان ماكان كلها لا تستطيع كصاحب موقع صغير تركيب دروبال 8 وما بعدها عليها وهذي الكارثه وخارج توقعات مجتمع مطورين دروبال من الهواة والمستخدمين لدروبال لانها ليست تطوير فقط هذا تدمير كامل لنظام دروبال السابق واعادة بنائه من جديد وهذا القرار بصرف النظر عن اسباب قرار ادارة المشروع لابد من اعادة النظر عند كل مطور وصاحب موقع في استخدام دروبال الجديده كليا من كل النواحي وحدات برمجية وقوالب وحتى من جهه امنية لكثرة استخدام الادوات مع اطار سيمفوني بي اتش بي تخيل مكتبه واحده يصير فيها ثغره امنية انت محتاج الى تحديثها داخل اطار سيمفوني وباستخدام اداة composer حتى لو كان فيه خطا في هذي المكتبه داخل الاطار سيمفوني انت بتحتاج الى composer المشكله في كثرة المكتبات المستخدمه مع نظام دروبال نفسه والوحدات والقوالب مقارنه مع دروبال سابقا انت ما تحتاج الا تتابع القسم الامني في دروبال نفسها وهذا الشي المتوقع عند استخدام اي نظام ادارة محتوى انت تحتاج الى فريق عمل متكامل وصعب تعتمد على فريق دروبال الامني لوحده مع ضخامة اطار سيمفوني ومكتباته….
باختصار :
خيبة امل كبيرة لاغلب مطورين دروبال 7 وماقبلها واصحاب المواقع بقرار ادارة مشروع دروبال باستخدام طرف ثالث اطار سيمفوني والانتقال من المواقع الصغيره والمتوسطه الى المواقع الكبيره وزيادة تكلفة تشغيل دروبال 8 وما بعدها ما عدى اصحاب المواقع الكبيره بسبب الادوات اللي تقدمها دروبال بشكل مجاني ومفتوح المصدر مع الدعم لها …
قصة نظام backdrop cms :
دائما مجتمعات المصادر المفتوحه الحيه تجد فيها اشققات عند اتخاذ قرارات من قبل ادارة المشروع مثل ما صار مع دروبال 8 وما بعدها استهلاك موارد صعوبة في الترقية ادوات مطلوبه لادارتها الى اخره هنا ظهر اسمين الاول Nate Lampton وهذا من المبرمجين المبدعين في مجتمع دروبال وقديم جدا في دروبال يكفي ان اقول لكم وحدة webform هو مبدعها حتى تعلمون خلفيته الكبيره مع دروبال الثاني هو Jen Lampton كان لها دور كبير في نشر باك دروب بدأوا في صنع ما عجز عنه ادارة دروبال ان يقدموه لمجتمع دروبال وجاؤو بالمتوقع من دروبال بعد الاصدار 7 بالضبط اللي قدموه نظام ادارة محتوى للمواقع الصغيره والمتوسطه سهل وبسيط وقليل استهلاك الموارد ويعمل على اي استضافه مشتركه وبنفس فكرة ادارة دروبال كل من استخدم دروبال لن يجد تغير كبير الا في بعض الامور المعدوده على اصابع اليد الواحده مع وجود الوحدات السابقه الموجوده كوحدات في دروبال 7 تم اضافتها في قلب باك دروب مثل الرؤى views و panels المعروفه (تم تغييرها الى layouts ) مع تثبيت الوحدات وغيرها من لوحة التحكم بدون ftp وتحديث النظام من لوحة التحكم بشكل افتراضي مجرد تثبيت باك دروب ستجد الوحدات مثبته امامك وتم الاعتماد عليها في اغلب الصفحات ان كان في لوحة التحكم او الموقع بكامله وهذا يسهل التعديل من دون كتابة كود php كلها من لوحة التحكم بالاضافه انها قدمت ما كان يطمح له مستخدمين دروبال ووفرت لهم الادوات المطلوبه …
باختصار :
باك دروب جاء منقذ لاصحاب المواقع الصغيره والمتوسطه وكذلك المطورين جاء بما يتوقعه مستخدمين دروبال 7 الخلطه العجيبه = قلة استهلاك موارد + عمله على استضافه مشتركه + نفس فكره دروبال في ادارة الموقع + ادارة المشروع متفهمه ومرحبه باي مشاركه + الوحدات اللي كنا نحتاجها بكثره ونتماناها وهذا اللي كنت ابحث عنه ….
ملاحظه للمتعصبين :
مجتمع دروبال كان ومازال مرحب بمشروع باك دروب وكثير من مطورين الوحدات البرمجية والقوالب حولوها الى باك دروب مع وجود فريق باك دروب في لقاءات دروبال السنويه ولهم حضور قوي …
هل قلة فريق مشروع باك دروب يعتبرعيب :
من خبره طويله (من عام 2006 م) وانا اتابع المجتمعات المفتوحة المصدر على سبيل المثال nuke وما جاء بعدها المشكلة الاساسية ادارة المشروع وكبر المجتمع خصوصا من المطورين المبرمجين تحديدا هم من يساهم في تطوير اي مشروع مفتوح المصدر في باك دروب ادارة المشروع ممتازه لكن المشكلة في حجم المساهمين خصوصا الفريق صغير لكن استخدامهم لمنصة github سهل عليهم امور كثيره وانا من المعجبين بطريقة ادارة المشروع عن طريق قيت هوب في الاساس هو منصة المبرمجين الاولى وادارة المشروع قدمت المشروع لهم في مكانهم المناسب وما اكتفوا بتقديم المشروع فقط سمحت في المساهمه لكل مطور سواء بطرح الاخطاء مباشره في backdrop-issues خصصوا قسم خاص بها ومحاولة حلها او الاقتراحات وما اكتفوا بهذه فقط سمحوا لهم باضافة اضافاتهم مباشره على قت هوب backdrop-contrib وهذي الخطوه بالذات اتوقع انها سرعت في نقل الوحدات من دروبال 7 الى باك دروب port انت ما تحتاج الانتقال الى اكثر من موقع وتشتت الفريق من مكان المطورين الخاص بهم قت هوب افتح المجال لهم واترك الباقي عليهم وهذا ما نجحوا فيه ادارة مشروع باك دروب بامتياز تخيل انه يتم pull للمشروع الرئيسي باك دروب او الوحدات او القوالب يوميا و issues كذلك اللي اطلع على الفريق بيستغرب مثلي حتى تابعتهم عن قرب وعرفت ان الادارة الجيده تستغل كل الادوات المتوفره حتى تنجح المشروع وهذا بالفعل اللي حصل في باك دروب اذا وفرت لهم ادوات ممتازه وعلى منصتهم المناسبه لهم مع مخزون كبير من وحدات دروبال 7 وطريقة تحويلها الى باك دروب سهله ولها شروحات وحتى القوالب محرك القوالب في باك دروب هو نفسه محرك قوالب دروبال 7 ….
الاختلاف بين دروبال 7 و باك دروب :
في دروبال 7 كان فيه جمله متداوله بين مستخدمين ومطورين دروبال حتى تعمل دروبال لابد من كاش خزن مؤقت خصوصا مع استعلامات قاعدة البيانات وكان memcache احد الادوات المطلوبه في الاستضافه المشتركه اذا كنت بتستخدم دروبال بدونها الموقع بيكون بطيئ جدا في باك دروب انت ما تحتاج الى اي اضافة فقط opcache وهذا متوفر حاليا في استضافه مشتركه وبيكون الموقع سريع جداً بسبب اعادة بناء الاستعلامات واهمها ادخال نظام ادارة الاعدادات واستخدام ملفات json في حفظ الاعدادات بدل قاعدة البيانات خصوصا جدول Variables المشفر وطبعا عند زيارة الموقع بيتم فك تشفيرها وهذا كان يستهلك موارد كبيره مع كثرة الاعدادات وهذا قلل ايضا الاستعلامات للزائر في باك دروب انت تحتاج الا الى استعلام واحد فقط الباقي انت تاخذه من ملفات الاعدادات json تخيل الفرق وصل الى 30% فرق بين دروبال 7 و باك دروب طبعا لصالح باك دروب بالاضافه انه تم الاستغناء اكواد كثيره في قلب core النظام اللي ورثته دروبال 7 من اصدارات قديمه في باك دروب وهذا سبب سرعة تصفحها العجيبه مقارنه بدروبال سواء 7 او حتى 8 وما بعدها مع ملاحظه انها لا تحتاج memcache او redis مثل ما كان في دروبال 7 او 8 وما بعدها بسبب ملفات الاعدادات json ….
تضمين الوحدات المطلوبه في باك دروب :
تم اضافة وحدات مهمه وضرورية في باك دروب منها الرؤى views الخاصه بي استعلامات قاعدة البيانات من لوحة التحكم تقدر تستعلم عن اي بيانات من خلال واجهه رسومية وتصدرها في باك دروب بكل سهوله في دروبال 7 كنا نحتاج الى وحدات اخرى اهمها ctools اللحين في باك دروب تم اضافة الرؤى في قلب النظام واكيد بيكون له الاولويه في دعمه من قبل فريق التطوير وهذي النقطه بحد ذاتها مهمه لكل صاحب موقع ومطور مواقع الجميل انه تم الاعتماد عليها حتى في اغلب صفحات وصناديق لوحة التحكم وبالامكان التحكم فيها من لوحة التحكم حتى تخصصون لوحة التحكم بكل سهوله ...
وحدة panels في دروبال 7 تم اضافتها الى نواة وقلب باك دروبال مع تعديل اسمها الى الانساق layouts وهذي بالذات تم الاعتماد عليها اعتماد كلي واعطت باك دروب مرونه اكبر في عرض المحتوى في الموقع بكامله حتى لوحة التحكم لها نسق خاص بها مع امكانية تحديد مكان عرض كل نسق من لوحة التحكم وبدون كتابة كود php واحد مع امكانية انشاء نسق جديد تقسيم للصفحه واضافتها للنظام وكل اللي تحتاجه html فقط والهدف منها اضافة الصناديق لها في دروبال 7 كنا نضيف مناطق الصناديق للقالب نفسه في ملف info اللحين في باك دروب ما يحتاج المصميم ليها لانها تم نقلها بالكامل الى الانساق ....
ميزة اضافة Project Installer في نواة باك دروب:
هذي الاضافه بالذات كنا نتمناها في دروبال 7 وما قبلها بامكانكم بكل سهولة تثبيت الوحدات والقوالب والانساق من لوحة التحكم بعد الدخول عليها يعرض لهم مستودع الوحدات على سبيل المثال وتختار الوحده المناسبقه ثم تتبع الوحدات الجميل اذا كان الوحده تتطلب وحده اخرى يتم سحبها وفك الضغط عنها في الموقع وتفعيلها بدون تدخل منك مع خيار البحث الممتاز وبامكانكم من لوحة التحكم عرض معلومات الوحده او القالب او النسق في لوحة التحكم قبل التثبيت طبعا في دروبال 8 ومابعدها صعب تطبيق الفكره نفسها بسهولة ومميزات Project Installer اللي في باك دروب ...
هذا شرح فيديو لها
ميزة تحديث نظام باك دروب من لوحة التحكم :
وهذي الخاصية كنا نتمناها في دروبال 7 تم توفيرها في باك دروب بشكل افتراضي في السابق على الاستضافات المشتركه كنا نحمل نسخة دروبال ونفك الضغط عنها وبعدها رفعها عن طريق FTP اللحين مع باك دروب ما نحتاج هذي كلها النظام يتكفل بها من لوحة التحكم تقدر تحدث نواة النظام من لوحة التحكم مثل الوحدات والقوالب والانساق كل اللي تحتاجه ضبط التصاريح للمجلدات وبعدها ترتاح نهائي من كابوس التحديث ..
مشاكل بعد الانتقال :
الموقع بعد التحويل الى باك دروب مع محتوى فوق 2000 صفحه بدون مشاكل على البنية الاساسية للمحتوى العنواوين والحقول والروابط بكاملها مع التركيز على موقع ملحقات كل التصاميم يعتمد اعتماد كلي على حقلين الصور والمرفقات الملفات المضغوطه تم نقلها من مسار \sites\default\files الى files بدون فقدان ملف او صوره واحده الحمدلله لكن بقت في قاعدة البيانات مخلفات دروبال 7 واعتقد انه يحتاج الى تنظيف كامل لها او على الاقل تفرغ الجداول الغير ضرورية في باك دروب مثل جداول الوحدات في دروبال 7 و جدول **variable** و **registry** وغيرها وهذي تحتاج الى مراجعه لها لكن النتيجه مذهله الافضل استخدام وحدة Backdrop upgrade status في دروبال 7 قبل التحويل حتى تحذفون كل الوحدات اللي ما يقابلها وحدات في باك دروب وبيفرق معكم كثير حجم قاعدة البيانات وتنعكس على الاداء بشكل واضح …
لماذا لم اختار ووردبريس بدل باك دروب :
هذي بتسبب مشاكل عند غير المنصفين والمطورين المطلعين بسبب شهرة ووردبريس وعدم استخدام باك دروب تشكل عندهم صورة ذهنية ان كل انظمة ادارة المحتوى صعبه وسيئة ومافيها امكانيات تطوير وتطويع لاي غرض مثل ووردبريس بسبب الدعاية لها بالرغم من امكانيات باك دروب المميزة وامكانية تطويرعها لاي تخصص تحتاجونها مع تكلفتها البسيطه مقارنه مع ووردبريس عطوها تجربه ومتأكد ان اللي يبحثون عن مصلحتهم ومصلحة عملائهم بتتغير نظرتهم عن باك دروب …
1. الحاجة للإضافات المدفوعة (Plugins) والتكلفة المادية 💰
- في ووردبريس (WordPress): النظام مجاني، لكنك ستصطدم بجدار "الإضافات المدفوعة" سريعاً. لتحويل موقعك إلى موقع احترافي يتضمن نظام قوالب مرن وتصاميم متقدمة (مثل استخدام Elementor Pro أو Divi)، أو إضافة فلاتر بحث معقدة، أو نماذج اتصال متطورة، أنت مجبر على دفع اشتراكات سنوية قد تصل لمئات الدولارات. بدون الدفع، ستكون ميزاتك محدودة جداً.
في باك دروب (Backdrop CMS): فلسفة النظام مأخوذة من دروبال؛ كل شيء مجاني ومفتوح المصدر بالكامل (100% Free). لا توجد "نسخ برو" أو إضافات مدفوعة. الميزات المتقدمة مثل بناء صفحات وتصاميم معقدة (عبر نظام Layouts المدمج)، وأداة فلاتر وعرض المحتوى المتطورة (Views)، كلها مدمجة في نواة النظام مجاناً وبدون أي تكاليف مخفية.
مرونة التصميم وملحقات القوالب *(Theme Layouts) 🎨
- في ووردبريس (WordPress): لتغيير تصميم جزئية معينة من الموقع أو بناء نظام "ملحقات تصاميم" مخصصة لكل قسم، ستحتاج إلى أدوات بناء الصفحات (Page Builders) المدفوعة كما ذكرنا، وتلك الأدوات تستهلك موارد السيرفر وتجعل كود الموقع متضخماً ومليئاً بالأخطاء البرمجية (Bloated Code).*
- في باك دروب (Backdrop CMS): يحتوي على نظام Layouts (الانساق) المدمج في النواة كبديل متطور عن نظام الكتل القديم. هذا النظام يتيح لك تقسيم الموقع برمجياً، وإنشاء مظهر مخصص لكل صفحة أو لكل تصنيف (Taxonomy) والتحكم في عرض الحقول في المحتوى نفسه بمرونة مذهلة وبأداء فائق السرعة دون كتابة كود ودون الحاجة لأي ملحقات خارجية.
الحاجة إلى سيرفرات خاصة واستهلاك الموارد (Hosting & Traffic) 🖥️
- في ووردبريس (WordPress): يعاني من معضلة استهلاك الموارد بسبب كثرة الإضافات. عند وصول الموقع لعدد زوار متوسط، وبسبب تراكم طبقات الكاش والإضافات، ستحتاج قسراً للترقية إلى سيرفر خاص (VPS) حتى لا يتم إغلاق موقعك من قِبل الاستضافة المشتركة بتهمة استهلاك المعالج (CPU). الغريب هنا أن ووردبريس قد ينهار تحت ضغط عدد زوار أقل بكثير مما يمكن لباك دروب تحمله.
- في باك دروب (Backdrop CMS): بفضل معماريته النظيفة وقراءة الإعدادات من ملفات JSON، فإن استهلاكه للموارد ضئيل جداً. الموقع يمكنه استقبال حجم زوار ضخم (Traffic) والعمل بكفاءة وثبات صاروخي على استضافة مشتركة رخيصة، دون أي حاجة للانتقال لسيرفرات خاصة مكلف.
لماذا استخدمت سيرفر اقتصادي بدل استضافه مشتركه :
حجم الموقع فوق 7 جيجا واغلبها صور بدقة عالية وملفات مضغوطه لذلك الاستضافه المشتركه مستبعده بسبب القيود والاتجاه الى سيرفر اقتصادي بقيمة الاستضافه المشتركه تقريبا واقل من قيمة تجديد الاستضافه المشتركه وهذا الفخ اللي يقع فيه اصحاب المواقع الصغيره مع الاستضافات المشتركه يغرونكم في اول سنه لكن مع التجديد يرتفع السعر …
هل ممكن موقع بهذا الحجم تديره ووردبريس مع اضافاتها بنفس مواصفات السيرفر اللي بيعمل عليه باك دروب بنفس عدد الزوار ؟
طبعا لا بدون ادنى شك ووردبريس بيحتاج الى ترقية السيرفر لكن باك دروب بيتحمل ضعف ان ما كان اضعاف زوار وردبريس بكل سهوله وبدون الحاجه الى ترقية السيرفر …
ماذا عن استخدام كلوود فلير (Cloudflare)؟ هل ينقذ ووردبريس ؟
قد يظن البعض أن وضع الموقع خلف شبكة كلوود فلير وتفعيل الـ CDN وجدار الحماية سيحل مشكلة استهلاك الموارد في ووردبريس ويجعله يتساوى مع باك دروب. الحقيقة هي أن كلوود فلير ممتاز في حجب الهجمات وتخزين الصور والملفات الساكنة لتسريع الموقع، لكنه يقف عاجزاً أمام العمليات الديناميكية.
في موقع ملحقات تصاميم، يقوم الزوار باستمرار بالبحث، استخدام الفلاتر، وتصفح الأقسام. هذه العمليات تتجاوز كلوود فلير وتصل مباشرة لقلب السيرفر. هنا يظهر التفوق الكبير لـ Backdrop CMS حيث يتعامل مع هذه الاستعلامات الديناميكية بخفة متناهية عبر ملفات JSON وبنية كود نظيفة، بينما ينهار ووردبريس تحت وطأة الإضافات الثقيلة التي تلتهم معالج السيرفر وراماته المحدودة عند أول جولة بحث مكثفة من الزوار.
حتى في أبسط عمليات البحث..؟
البعض يعتقد ان غياب فلاتر البحث المعقدة واقتصار الموقع على مربع بحث تقليدي قد يتساوى فيه النظامان. لكن الحقيقة التقنية مختلفة تماماً, فالبحث الافتراضي في ووردبريس لا يعتمد على فهرسة مسبقة، بل يقوم بمسح أعمى ومباشر لقاعدة البيانات مع كل نقرة بحث (باستخدام استعلامات LIKE الثقيلة). في موقع ملحقات تصاميم يتجاوز حجمه 7 جيجابايت، هذا البحث الأعمى كفيل بإنهاك المعالج فوراً وتجمد السيرفر.
على الجانب الآخر، يمتلك Backdrop CMS نظام فهرسة مدمج وذكي في نواته. فهو يقوم بفهرسة الكلمات مسبقاً في جداول خفيفة مخصصة، وعندما يبحث الزائر، يتم جلب النتيجة في أجزاء من الثانية من الفهرس الجاهز دون الحاجة للبحث في ملفات الموقع الضخمة. هذا يعني أن سيرفرك المتواضع ذو الـ 1 جيجا رام سيظل مستقراً وبارداً حتى لو تكالب الزوار على مربع البحث في نفس اللحظة...
ملاحظه السيرفر nginx+php+mysql وبدون اي اضافة كاش لباك دروب فقط opcach وهذي موجوده في الاستضافات المشتركه
