يؤكد فريق تطوير Gutenberg أنه لن يتم إهمال Meta Box API رسميًا

المناقشة المتعلقة بكيفية تعامل Gutenberg مع الصناديق الوصفية التي تم تسخينها خلال عطلة نهاية الأسبوع بعد أن علق أحد المشاركين على مشكلة GitHub بقلق فيما يتعلق بإزالة دعم meta box من أحدث معلم.

قالsteveangstrom: "أرى أن هذه القضية الحيوية قد تمت إزالتها من أي معلم". "لقد تم إلغاء ترتيب الأولويات مرة أخرى بينما تحصل أجراس وصفارات تحرير المدونة على الكثير من العمل وتتم إضافتها إلى الإصدارات التجريبية. هذا أمر مقلق للغاية بالنسبة لمستقبل WordPress باعتباره CMS ".

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

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

"هل من الممكن استبدال محرر منشورات TinyMCE الحالي بـ Gutenberg مع ترك باقي الواجهة ، بما في ذلك مربعات التعريف والخطافات الحالية ، دون تغيير؟" سأل كيفن هوفمان. عندما أوضح Nylen أن Gutenberg ، كما هو مكتوب اليوم ، يُقصد به أن يكون محررًا لما بعد post_content ، لخص هوفمان المخاوف التي أعرب عنها العديد من المطورين:

إذا كان المقصود من Gutenberg حقًا أن يكون محررًا لما بعد post_content ، فيجب ترك المربعات الوصفية بمفردها لأنها غير معنية بـ post_content .

علاوة على ذلك ، فإن الحاجة إلى واجهة برمجة التطبيقات (API) لترجمة مربعات التعريف PHP إلى مربعات وصفية لـ React هي مشكلة مصنّعة. ليس من الضروري أن تكون مشكلة ، لكنها أصبحت مشكلة لأنه في مكان ما على طول الخط تقرر أن إعادة كتابة محرر post_content يجب أن تغير تمامًا طريقة عمل المربعات الوصفية.

لقد أوجزت التحدي الهائل لكتابة مثل هذا API في # 2251. تعتبر ترجمة مربعات PHP الوصفية إلى React لحل الحقول المخصصة الشائعة مثل ACF تحديًا كافيًا ، ناهيك عن محاولة القيام بذلك لكل تطبيق Meta box موجود اليوم ، سواء كان شائعًا أم لا. لا مقياس.

نظرًا لأن المساهمين في Gutenberg شاركوا بأنهم قد بدأوا للتو النظر في مشكلة meta box ، فقد أصبح من الواضح الآن سبب عدم وجود خارطة طريق لكيفية تعامل المشروع مع المربعات الوصفية لـ PHP "القديمة". في يوليو ، قال Nylen ، "إذا كان عليّ أن أخمن إلى أين سننتهي هنا: سيتم نقل صناديق التعريف الحالية إلى منطقة" قديمة "وسنوفر واجهات برمجة التطبيقات والوثائق والأمثلة لتسجيل كتلة metox-style" الجديدة " -الأشياء. "

يتابع مطورو البرنامج المساعد الذين يديرون مكتبات صندوق التعريف والوكالات والأطراف المعنية الأخرى البطاقة لمعرفة كيفية التخطيط لـ WordPress 5.0 ، والذي تم استهدافه كإصدار Gutenberg. سأل أندري سافتشينكو ما إذا كان WordPress يخطط لإيقاف واجهة برمجة التطبيقات meta box API رسميًا ، والتي حصلت أخيرًا على إجابة واضحة من الفريق. أجاب ماتياس فينتورا:

"هل ينوي WordPress إيقاف Metabox API رسميًا؟"
رقم.

السؤال الذي لم تتم الإجابة عليه بشكل كامل حتى الآن هو كيف تعمل المربعات الوصفية في سياق محرر جوتنبرج. هل يجب أن يظلوا على حالهم أم يتطورون؟ كيف يمكننا المضي نحو أهداف التصميم بأقل قدر ممكن من الاضطراب؟

ظلت هذه القضية عالقة ليس بسبب نقص الرغبة ، ولكن بسبب نقص الموارد. ينصب التركيز الأساسي لهذا المشروع على تقديم واجهة تحرير محتوى غنية تعمل على تحسين المعالجة المباشرة لمحتوى المستخدم من خلال فكرة الكتل. (بعد أن استخدمت meta-box على نطاق واسع لمختلف المشاريع ، أعتقد أن الكتل يمكن أن تقدم خطوة أفضل إلى الأمام للعديد من تلك الاحتياجات مع توفير تجربة مستخدم أفضل.)

أدرجت Ventura عدة خيارات نظر فيها الفريق للتعامل مع الصناديق الوصفية وطلب المساعدة من المجتمع لبناء أفضل حل:

• إذا اكتشفنا أن meta-box مسجل ، فيمكننا الرجوع إلى الواجهة القديمة ، ولن يتغير شيء.
• يمكننا تقسيم تحرير المحتوى وتعديل المعلومات الوصفية إلى شاشتين أو مرحلتين.
• يمكننا محاولة معرفة مدى جدوى عرض هذه كما هي (PHP) أسفل المحتوى: # 2251.
• يمكن للقالب / البرنامج المساعد / CPT إلغاء تسجيل الواجهة الجديدة حسب الحاجة.
• يمكن تحويل العناصر المختلفة التي تعتمد على مربعات التعريف إلى كتل لواجهة المستخدم (لا تزال تخزن البيانات بشكل منفصل).
• يمكننا تنفيذ قابلية توسيع مربعات التعريف القائمة على واجهة برمجة التطبيقات مثل Fields API.

عند الضغط عليه للإجابة على سؤال حول سبب تضمين المربعات الوصفية في سياق المحرر الجديد ، أوضح رئيس تصميم Gutenberg Joen Asmussen كيف قرر الفريق تضمين مربعات التعريف في نطاق المشروع:

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

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

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

علق Xavi Ivars على هذه القضية: "أحصل تمامًا على مقدار العمل الذي تم إنجازه نحو نهج استبدال" الشاشة ". "لكن ألا ينبغي أن يعود المشروع الذي بدأ بهدف استبدال" محرر محتوى المنشور "إلى المجتمع قبل أن يقرر من جانب واحد أنه سيحل محل شاشة المحرر بالكامل؟"

لم يتم إهمال واجهة برمجة تطبيقات meta box ولكن لا يوجد أيضًا مسار واضح لكيفية دعم Gutenberg للصناديق الوصفية لـ PHP "القديمة". قال فريق جوتنبرج إن المشكلة لم تحل بسبب نقص الموارد. يحتاج المشروع إلى مدخلات المجتمع وتواصل أفضل إذا كان الفريق سيصل إلى حل من شأنه أن يرشد غالبية مواقع WordPress بسلاسة إلى عصر Gutenberg بأقل قدر من الانقطاع.

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