استكشاف تحرير الموقع بالكامل باستخدام سمة Q WordPress
نشرت: 2020-10-06لقد كنت أنتظر بفارغ الصبر اللحظة التي يمكنني فيها تثبيت سمة واختبار ميزة تحرير الموقع بالكامل في Gutenberg. على العموم ، في كل مرة أختبرها خلال الأشهر القليلة الماضية ، شعرت بأن التجربة مكسورة تمامًا. هذا هو السبب في أنني ظللت متشككًا في رؤية ميزة الأرض في WordPress 5.6 في ديسمبر.
موضوع Q لـ Ari Stathopoulos هو الموضوع الأول الذي يبدو أنه مثال عمل لائق. من الصعب معرفة ما إذا كانت هذه ضربة حظ مع التوقيت أو أن هذا الموضوع المحدد تم بناؤه بشكل صحيح - Stathopoulos هو ممثل فريق لفريق Themes Team. انخفض Gutenberg 9.1 الأسبوع الماضي مع استمرار العمل نحو تحرير الموقع.
Q تجريبية بقدر ما تحصل عليه. أطلق فريق Themes دعوة مفتوحة للموضوعات التجريبية القائمة على الكتلة منذ مارس من هذا العام. ومع ذلك ، لم يشارك الكثيرون الفريق في هذا العرض. إذا تمت الموافقة عليها ، فإن Q ستكون أول سمة قائمة على الكتلة يتم نشرها في دليل WordPress الرسمي. ولا يزال يتعين عليها أن تشق طريقها من خلال عملية المراجعة القياسية ، في انتظار دورها في الأسابيع المقبلة.
بشكل عام ، يظل تحرير الموقع بالكامل تجربة محبطة ومربكة. ما زلت متشككًا بشأن استعداده ، حتى في شكل تجريبي ، للتباهي بالعالم في WordPress 5.6.
ومع ذلك ، يعد Q موضوعًا مثيرًا للاهتمام لاستكشافه في هذه المرحلة لكل من المستخدمين النهائيين ومطوري السمات. يمكن للمستخدمين تثبيته والبدء في تعديل شاشة تحرير الموقع عبر المكون الإضافي Gutenberg. يمكن للمطورين التعرف على كيفية توافق الأنماط والقوالب وأجزاء القوالب العامة معًا من نسق العمل.
باستخدام محرر الموقع
تتطلب سمة Q تمكين المكون الإضافي Gutenberg ووضع تحرير الموقع بالكامل. بشكل عام ، لا يُسمح بطلب مكون إضافي للقوالب الموجودة في الدليل. ومع ذلك ، يُسمح لموضوعات جوتنبرج التجريبية بتجاوز هذا المبدأ التوجيهي.
وأشار ستاثوبولوس إلى أن الموضوع تجريبي للغاية ولا ينبغي استخدامه في موقع الإنتاج. ومع ذلك ، فهو يأمل في أن تركز المزيد من العيون على تحرير الموقع بالكامل.
وأشار إلى أن العديد من العناصر معطلة ، مثل أرشيفات الفئات التي لا تظهر المشاركات الصحيحة. هذا قيد حالي على كتلة الاستعلام في جوتنبرج. ومع ذلك ، فإن إحدى أفضل الطرق للعثور على هذه الأنواع من القضايا والتعرف عليها هي أن يكون لديك موضوع يواكب وتيرة التطور.
في الوقت الحالي ، يشعر محرر الموقع أنه يقضم أكثر مما يمكنه مضغه. لا يستطيع المستخدمون فقط تحرير تخطيط الصفحة وتصميمها ، بل يمكنهم أيضًا تعديل محتوى المنشور الحالي مباشرةً - لا تحاول ذلك في المنزل إلا إذا كنت على استعداد لتبديل عناوين منشوراتك إلى الرابط الثابت الموصّل. هل ينبغي أن يتولى محرر الموقع المهمة المزدوجة المتمثلة في تحرير التصميم والمحتوى؟ إذا كان الأمر كذلك ، فهل ينبغي معالجة التصميم وتحرير المحتوى في مواقع منفصلة على المدى الطويل أم يتم دمجهما في ميزة واحدة؟
إنه شعور خام. انها ليست موجهة نحو المستخدمين في هذه المرحلة.
النقطة المضيئة في محرر الموقع هي التقدم الحالي في أجزاء القالب في المحرر. أجزاء النموذج هي في الأساس "وحدات" تتعامل مع جزء واحد من الصفحة. على سبيل المثال ، سيكون للسمة النموذجية جزء قالب رأس وتذييل الصفحة. في الوقت الحالي ، يمكن للمستخدمين إدخال أجزاء قالب مخصصة أو تبديل جزء قالب لآخر. هذا يفتح عالمًا من الاحتمالات ، مثل اختيار المستخدمين بين تصميمات رأس متعددة (أجزاء قالب) لمواقعهم.
يتمثل الجانب السلبي لنظام القوالب بأكمله في أنه يبدو منفصلاً جدًا عن محرر الموقع بحيث يصعب تصديق أن المستخدم العادي سيفهم ما يجري. توجد القوالب وأجزاء القوالب ضمن قائمة المظهر في المسؤول. محرر الموقع هو عنصر قائمة منفصل ذو مستوى أعلى. بدون أي معرفة مسبقة بكيفية عمل هذه القطع معًا ، قد يكون الأمر مربكًا.
عملت أجزاء النموذج معي في محرر الموقع منذ البداية. ومع ذلك ، لم يعملوا في الواجهة الأمامية في البداية. تلقيت باستمرار رسالة "لم يتم العثور على جزء من النموذج" لساعات. بعد ذلك ، في مرحلة ما - سواء من خلال السحر أو الحفظ العشوائي الذي يجمع كل شيء معًا - بدأت الميزة في إخراج أجزاء قالب الرأس والتذييل المفقودة سابقًا.
لمحة عن مستقبل تطوير الموضوع
يحتوي موضوع Q على عدد قليل من قواعد الأنماط ، والتي يتم تحميلها مباشرةً في قسم <head> بالموقع بدلاً من إضافة ورقة أنماط إضافية. يعتمد على أنماط كتلة جوتنبرج في الواجهة الأمامية مع بعض التجاوزات الطفيفة. يتم التعامل مع معظم الأنماط المخصصة الأخرى عبر نظام الأنماط العالمي ، والذي يتم سحبه من ملف التكوين experimental-theme.json (سيكون theme.json في المستقبل).
يطرح السؤال عما إذا كانت السمات ستحتاج بالضرورة إلى الكثير في طريق CSS عند تحرير الموقع بالكامل.
إذا كان WordPress يسمح للمستخدمين بتهيئة معظم الأنماط عبر خيارات الحظر وتجاوزات الأنماط العامة ، فقد لا تحتاج السمات إلى أكثر من ملفات التكوين الخاصة بهم. بعد ذلك ، سينزل إلى تسجيل أنماط وأنماط الكتلة المخصصة.
إذا كان هذا هو المستقبل الذي نتجه نحوه ، فيمكن لأي شخص بشكل أساسي إنشاء سمة WordPress. ويمكن مشاركة هذه الأجزاء ، مثل أجزاء النماذج والأنماط ، بين أي موقع. في هذا المستقبل ، قد لا تهم الموضوعات بعد الآن.
في العام الماضي ، اقترح مايك شينكل إهمال نظام السمات تمامًا واستبداله بمكونات الويب.
قال: "بدلاً من البحث عن موضوع يحتوي على جميع الميزات التي يحتاجها المرء - والتي وجدت دائمًا أنها تحد من الخيارات إلى الصفر - يمكن لمالك الموقع البحث عن المكونات والوحدات التي يحتاجون إليها ثم تجميع موقعهم من تلك الوحدات" . "يمكنهم اختيار عنوان ، وتذييل ، وبطل الصفحة الرئيسية ، ومجموعة من بطاقات المقالات ، ووحدة تسعير ، وما إلى ذلك."
كلما بدأت في تعديل الموقع بالكامل ، كلما شعرت أن هذا هو الممر الذي سيندمج فيه في النهاية. تخيل مستقبلاً حيث يمكن للمستخدمين النهائيين انتقاء واختيار القطع التي يريدونها وببساطة اجعلها تبدو بشكل صحيح في الواجهة الأمامية.
من المثير التفكير في هذا الاحتمال. لديَّ أنا وشينكل خلفية في البرمجة أكثر مما لدينا في التصميم. من المنطقي من هذا النوع من العقلية التحليلية وضع كل شيء في صناديق مرتبة وقابلة لإعادة الاستخدام لأن إعادة الاستخدام هي حجر الزاوية في البرمجة الذكية.
ومع ذلك ، فإنني قلق بشأن حالة التصميم في مثل هذا النظام مع العديد من الأجزاء القابلة للاستبدال. هل سيتمكن المصممون من اتباع نهج شاملة لتطوير الموضوع ، وإنشاء قطع فنية معقدة حقًا؟ هل سيقوم هذا النظام بشكل أساسي بإنشاء شبكة من مواقع قطع ملفات تعريف الارتباط؟ أم ، هل سيجد المصممون ببساطة طرقًا للتفكير خارج الصندوق أثناء وجودهم ضمن قيود نظام الكتل؟