ثيمات FSE و WordPress: كيف يبدو MVP؟

نشرت: 2021-02-04

نشرت Josepha Haden Chomphosy ، المديرة التنفيذية لـ WordPress ، متابعة لمخططها العام المقبل. تم طرح الأسئلة حول الشكل الأدنى للمنتج القابل للتطبيق (MVP) لتحرير الموقع الكامل (FSE) ، والذي من المتوقع أن يكون جاهزًا في المكون الإضافي Gutenberg في أبريل. يقوم الفريق الأساسي أيضًا بالتصوير لإطلاق FSE في يونيو في WordPress عندما يشحن WordPress 5.8.

تبدو هذه أهدافًا نبيلة ، لكن أعضاء مجتمع تطوير WordPress والأعمال تركوا يسألون ، "ما هو MVP for FSE؟" هذا ليس سؤال جديد. سواء أكان ذلك هو الوتيرة السريعة للتطوير ، أو تعطل الاتصال ، أو إخفاء الكثير من المشروع خلف طبقة فوق طبقة من مشكلات GitHub ، فقد يكون من الصعب متابعتها. لا توجد صفحة ويب كبيرة توضح كل خطوة بتفاصيل دقيقة عن المكان الذي يسير فيه المشروع. يمكن أن تبدو المعلومات في بعض الأحيان مبعثرة. يمكن أن يؤدي هذا إلى توقف مطوري الطرف الثالث وأصحاب الأعمال الذين يحتاجون إلى معرفة ما يمكن توقعه لتحديث منتجاتهم.

أعرب Joost de Valk ، كبير مسؤولي المشتريات في Yoast ، عن إحباطه من العملية في التعليقات. ناقشنا هذا لاحقًا بمزيد من التفصيل.

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

يشترك في بعض نفس الاهتمامات مثل الآخرين في المجتمع الذين يشعرون أنه لا توجد عملية مطبقة لـ MVP.

قال "ولا يوجد شيء من هذا القبيل". "الرؤية بدون إعدام هي مجرد هلوسة."

قالت تشومفوسي إنها كانت على علم بالترابط. قالت: "أرى أيضًا أن المعلومات التي نشرناها ليست في منشور منظم ويمكن متابعته من شأنه أن يساعد الأشخاص على اتخاذ قرارات جيدة نيابة عن 39٪ من الويب".

أشارت إلى بطاقة تسرد ستة (الآن سبعة) معالم. كل من هذه المعالم ، عند أخذها معًا ، تمثل المكان الذي يجب أن تكون فيه FSE بالنسبة إلى MVP.

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

فيما يلي تفصيل للمعالم التي يجب أن تصل إلى الاكتمال قبل أن نرى الإصدار الأول من FSE land في WordPress:

معلم 1: البنية التحتية وواجهة المستخدم

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

تسمح المرحلة الأخيرة من هذا الحدث للمستخدمين بتحرير القوالب من داخل محرر المنشورات ، والتبديل الفعال بين تحرير المحتوى والتصميم. قام برنامج FSE Outreach مؤخرًا باختبار هذه الميزة للحصول على تعليقات بعد Gutenberg 9.6.

المعلم 2: التصفح

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

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

المعلم 3: التصميم

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

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

المعلم 4: قوالب الموضوع

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

من المسلم به ، أنني حزين لرؤية أن كتل الإشارات المرجعية / الروابط من غير المرجح أن تمضي قدمًا. بينما يتم إهمال الميزة ، ما زلت أشعر بالحنين إلى أيام المدونات الجيدة. ربما يكون من الأفضل ترك هذا البرنامج المساعد. قد يكون إحياء المكون الإضافي Link Manager جيدًا.

المرحلة 5: كتلة الاستعلام

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

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

المعلم 6: قالب التنقل

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

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

المعلم 7: الاعتماد التدريجي

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

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