لم يمر أكثر من شهر ونصف على إطلاق نسخة 5.7 من نظام WordPress، حتى سُلِّطت الأضواء على WordPress 5.8 الإصدار القادم من النظام، والذي من المتوقع أن يحمل في طيّاته تغييرات جذرية عديدة، وتطورات هائلة في تجربة المُستخدمين.
فبالرغم من التغييرات المتعددة التي تحملها الـ Patches هنا أو هناك كل فترة، وعملية سد الثغرات الأمنية وإصلاح الأخطاء داخل النظام بشكلٍ دوري، إلّا أن المستخدمين والمطورين متعطشون للتغيير الجذري الذي من المتوقع أن يحمله نظام WordPress في إصداره 5.8.
لا زال هذا الإصدار المتوقع بعيد المنال نوعًا ما، لكننا نملك خارطة طريق واضحة المعالم نوعًا ما، قد تُساهم في التنبؤ بما سيكون عليه النظام، وما سيحويه من تغييرات وتعديلات، قبل قدوم الموعد الرسمي لإصداره، نتحدث عنها في هذه المقالة.
النقطة الأساسية في التحديث: التحول إلى "التحرير الكامل للموقع"
النقطة الأساسية في هذا التحديث، هي تحويل عمليات التحرير والتصميم من شكلها الحالي، إلى طريقة "التحرير الكامل للموقع" أو “Full Site Editing (FSE)”، فما هي هذه الطريقة؟
في النظام الحالي، إذا أردت إضافة مكونٍ ما، أو إضافةٍ ما، ستحتاج إلى فتح قائمة Customizer، ثم اختيار المكون، وإضافته للمحرر، ومن ثم القيام بعملية التحرير من هُناك.
أما طريقة Full Site Editing، فهي تهدف إلى جعل كل تفاصيل عملية التحرير، تتم من خلال المكونات مباشرة، دون اللجوء إلى قوائم أو إضافات أو ما شابهها، أي أن جميع العناصر يتم التعامل معها داخل المحرر، وليس داخل أية قوائم أُخرى.
حتى الترويسة أو تذييل الصفحة، سيتم من خلال المكونات في طريقة Full Site Editing.
بحسب تسريبات شبه رسمية، فإن عملية التحرير الكامل للموقع ستعتمد بشكلٍ رئيس على الـ Themes المبنية من المكونات. أي أن قوالب المكونات والعناصر المنبثقة عن هذه القوالب، ستكون المكون الرئيس لبناء عملية التحرير الكامل للموقع.
إضافة لذلك، فإن مطوري نظام Gutenberg، وهم المؤسسون لنظام بناء الموقع من خلال المكونات المختلفة، فقد جهّزوا مكتبة بالعديد من المكونات المخصصة لعملية بناء وتصميم المواقع، والتي يُمكن استخدامها في عملية التحرير الكامل للموقع.
وبالرغم من بُعد وقت إصدار التحديث إلى نظام 5.8 للـ WordPress، إلّا أن عددًا من هذه المكونات تُعدُّ جاهزة للاستخدام، ومن بينها: عنوان الموقع، عنوان المقالة، محتويات المقالة، وغيرها.
"تهدف عملية FSE إلى التخلص من الـ Customizer والاعتماد على المكونات في بناء الموقع".
العملية ليست سهلة بل معقدة للغاية:
لقد طالب العديد من المُستخدمين، والمحررين، ومطوري أنظمة إدارة المحتوى “Content Management System (CMS)” بالإسراع في تطبيق عملية التحرير الكامل للموقع، إذ يعدّونها النقلة النوعية المنتظرة لنظام WordPress.
رغم ذلك، فالعملية ليست بهذه السهولة، بل إنها ستحتاج إلى وقت مطول وعملٍ كثير للقيام بالتغييرات الجذرية داخل Core البرمجة الخاصة بنظام WordPress.
ليس ذلك فحسب، بل إن مطوري نظام WordPress يسعون فقط للوصول إلى المستوى الأدنى التشغيلي للعملية، كأول أهداف تحديث 5.8، بسبب الصعوبات الكبيرة في تشغيل النظام على طريقة التحرير الكامل للموقع في وقتٍ قريب.
جدول زمني مقترح لتحديث ووردبريس 5.8
بحسب الموقع الرسمي لنظام WordPress، فقد اقترح المطورون أن يتم إطلاق عملية Feature Freeze – سنشرحها في الفقرة القادمة - في الـ 25 من الشهر القادم، أي بعد 91 يومًا من الإصدار الـ Alpha.
وبعد عملية Feature Freeze بأسبوعين، يتم إطلاق الإصدار الـ Beta من التحديث، على أن يتم في نهاية الأمر إصدار التحديث بشكلٍ نهائي في الـ 20 من شهر يوليو/تموز.
ما هي فترة Feature Freeze؟
كي تؤتي عملية تصحيح الأخطاء في أي برنامج أُكُلها، فإنه من المنطقي أن يقوم المطورون بعمليات اختبار للتغييرات المطلوبة في النظام خلال طور الـ Beta، والتي كُشفت خلال طور الـ Alpha، للتأكد من سير البرنامج في طريقه التي رُسِمت له.
لكن خلق موعدٍ آخر للقيام بالتحسينات والإضافات وإصلاح الأخطاء، سيكون له الأثر الجيد الذي سيسمح للمطورين بالتركيز على كل طورٍ على حدة، بدلًا من الانتقال مُباشرة من طورٍ إلى آخر.
من هنا، ظهرت فكرة فترة Feature Freeze، التي تهدف إلى إعطاء المطورين مهلة أسبوعين كاملين، للتعامل مع آلاف الـ Tickets المقدمة لهم، وإصلاحها قبل مرحلة الـBeta الذي ستختبر خلاله هذه الإصلاحات.
إيقاف التدريب والإرشاد بغية التركيز على برمجة النظام
لا شكَّ في أن عملية برمجة الـ Core في WordPress عملية صعبة للغاية، وتحتاج إلى كل الأيدي العاملة – إن صح التعبير- للتركيز على هذه العملية المعقدة.
لذلك، فإن المطورين قرروا إيقاف عمليات التدريب والإرشاد للمُتدربين، بهدف تركيز جهود المطورين المختصين على هذا الهدف.
بينما ستنقسم أهدافهم إلى 3 مهام رئيسة، وهي:
- حل المُشكلات التقنية التي تنشأ داخل إصدارات WordPress 5.7.x.
- تجميع الـ Tickets وتنظيمها معًا، ثم جدولة عملية حلّها.
- التعامل مع الـ Tickets المُرسلة حول عملية "التحرير الكامل للموقع" واختبار برمجيات Core.
في المحصلة، يدور تركيز المطورين الآن، وقبل إصدارهم لووردبريس 5.8، حول كيفية دمج العديد من الإضافات والمكونات وأدوات التصميم وغيرها في واجهة المُستخدم، دون المساس بإمكانية التفاعل داخل المحتوى وخارجه من المستخدم.
هذه المهمة، بحسب المطورين، لن تُترك للمُستخدمين ليقرروا إذا ما كان الإصدار القادم مُريحًا لهم أم لا، بل سيترك للمصممين والمطورين والمبرمجين المسؤولين عن إنشاء الإضافات والمكونات وأدوات التصميم وغيرها، مع شريطة أخذهم بعين الاعتبار أن عملهم يهدف لتقديم مُخرجٍ مخصص لهذا المُستخدم المذكور آنفًا.