يسعى مشروع WordPress Core Fields API إلى قيادة جديدة

في عام 2014 ، تولى سكوت كينجسلي كلارك ، المطور الرئيسي لـ Pods ، الدور الرئيسي لمشروع Metadata UI. في عام 2015 ، أعيد إنشاء مشروع Metadata UI باسم Fields API.

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

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

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

بقلب مثقل يجب علي أن أمرر الشعلة في هذا المشروع. بعد مئات الساعات من وقتي ، لم أعد أعتقد أنني أستطيع إحداث تغيير داخل نواة WordPress.

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

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

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

سكوت كينجسلي كلارك

المحاكمات والمحن لقيادة مشروع مفتوح المصدر

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

هل تتطلع إلى تسليم الشعلة إلى أي شخص على وجه الخصوص؟

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

لماذا تعتبر Fields API جزءًا حيويًا من مستقبل WordPress؟

ينظر الناس إلى WordPress اليوم ويتساءلون كيف نجوا بدون واجهة برمجة تطبيقات REST. حسنًا ، على الأقل أعلم أنني أفعل! يمكن قول الشيء نفسه عن Fields API على الرغم من أنها ليست موجودة بعد. هناك العديد من الحالات التي يكون فيها من المحبط بناء حلول لـ WordPress عبر جميع الخطافات المختلفة.

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

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

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

إذا تم تنفيذ Gutenberg بعد تشغيل Fields API ، فلن يكون الترحيل للأشخاص بهذه الصعوبة. يمكن أن يعرض Gutenberg تلقائيًا جميع واجهات API الخاصة بالحقول كما هو الحال بالنسبة للتوافق مع الإصدارات السابقة من مربع التعريف. كان سيبدو أجمل بكثير أيضًا.

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

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

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

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

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

أتمنى لو كان بإمكاني أن أكون في كل معسكرات WordCamp الكبيرة في الولايات المتحدة وأوروبا ، وأقوم بشكل أساسي بالضغط من أجل هذه الميزة. جمع المؤيدين وكذا ، يبدو وكأنه سياسة بطريقة ما. لقد توقفت في اجتماعات Core dev ، في محاولة لإحضارها. حاولت إضفاء الشرعية على الميزة من خلال امتلاك قناة مخصصة في WordPress Slack الرسمي ، ونشر التحديثات على https://make.wordpress.org/core/ ، وعقد اجتماعات أسبوعية.

في النهاية ، أعطيت الأولوية لوقتي للتطوير على مدار الوقت لجمع القوات. كان هذا هو السقوط ، لقد بدأت في الإنهاك سريعًا بعد عمليات إعادة الكتابة القليلة الأولى حيث كان لدي العديد من المسؤوليات الأخرى في مكان آخر على رأس Fields API.

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

هناك طلب على Fields API في جوهره ولكن لا يوجد عدد كافٍ من الأيدي لإنشائه. لماذا تعتقد ذلك؟

يركز الجميع في مكان آخر. هناك الكثير من مجالات WordPress التي تحتاج إلى اهتمام الناس. هناك أشياء مثل إمكانية الوصول تستحق اهتمامًا أكثر مما تحصل عليه. لكن التركيز بالنسبة لي يبدو أنه على Gutenberg و REST API.

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

ما هي النصيحة التي تقدمها لقائد مشروع Fields API التالي؟

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

لماذا تشعر بالمسؤولية الشخصية عن عدم كون المشروع أولوية أساسية؟

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

بالنظر إلى الوقت والجهد اللذين بذلتهما في المشروع في السنوات القليلة الماضية ، هل تشعر بأي شعور بالراحة عند تمرير الشعلة؟

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

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

في حين أن المستقبل القريب للمشروع غير واضح ، يتم تشجيع المهتمين بتوليه على قراءة المنشورات المميزة بعلامة Fields API على Make.WordPress.Core للتعرف على تاريخه. يمكنك أيضًا التحقق من صفحة Github الخاصة بالمشروع.

إذا كنت مهتمًا بتولي المشروع ، فيمكنك الاتصال بكلارك على Twitter أو Slack أو من خلال موقعه على الويب.