Gutenberg: هل تُعد إطارات iframe حلاً قابلاً للتطبيق طويل الأجل لصناديق التعريف؟

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

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

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

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

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

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

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

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

كل ما سبق ذكره ، أعتقد أنه من المهم النظر إلى ما سيتم استخدامه في المستقبل.

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

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

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

مرحبا كيفن،

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

هل من الممكن تشغيل نافذة محتوى من مربع تعريف يمتد إلى ما بعد إطار iframe؟

هل تقصد مثل Lightbox المشروط الذي يجب أن يشغل الصفحة بأكملها؟

هل تقصد مثل Lightbox المشروط الذي يجب أن يشغل الصفحة بأكملها؟

سيكون هذا مثالاً واحدًا ، لكنني أشير إلى أي سيناريو يجب فيه الكشف عن المحتوى ليس ضمن حدود iframe.

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

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

بمعرفة مدى سلبية تنفيذ iFrame فيما يتعلق بأصول المكون الإضافي / السمة ، أعتقد أن هذا يجب أن يؤدي إلى توقف المشروع مؤقتًا. الجواب الحقيقي هنا هو أن WordPress يشحن واجهة برمجة تطبيقات Fields https://github.com/sc0ttkclark/wordpress-fields-api - بدون ذلك ، فإن تنفيذ عمليات التمثيل الغذائي بفعالية باستخدام Gutenberg يكاد يكون مستحيلًا إذا كنا نهتم بالأداء على الإطلاق.

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

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

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

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

قد يكون من الجدير بالذكر أنه في منشور Core Customizer Dev Note Post الأخير كان هناك اهتمام بإزالة استخدام إطار iframe كتحسين. يبدو أن تنفيذ إطار iframe كحل هنا يعد خطوة إلى الوراء.

مرحبًا ماثيتوس ،

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

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

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

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

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

المصدر: https://yoast.com/gutenberg-alternative-approach/

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

مجرد الإشارة إلى أن هذا المفهوم يكسر عمليات التمثيل الغذائي الحالية ، لأنه لا يوجد مثيل TinyMCE مركزي للتواصل معه. بدلاً من دعم 80٪ من المستقلبات ، فإن هذا سيدعم 90٪ (لقد صنعت هذه الأرقام).

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

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

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

دعونا نبني الآن أفضل محرر ممكن.

عندما نعتقد أن الرؤية المثالية لـ Gutenberg جاهزة للشحن ، سيكون لدينا الوقت لمناقشة استراتيجيات مسار الترقية ...

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

لماذا تكرس آلاف الساعات لتطوير المحرر المثالي إذا لم يكن متوافقًا مع المواقع الموجودة؟

فقط لأكون واضحا،

• من المستحيل أن تكون متوافقًا بنسبة 100٪ مع مواقع الويب الخارجة بغض النظر عن الخيار الذي تختاره للمحرر لأن المكونات الإضافية لها وصول كامل إلى DOM ، وأي شيء تقوم بتعديله في dom يكسر التوافق إلى الوراء
• هناك طريقة واحدة فقط لضمان التوافق مع الإصدارات السابقة بنسبة 100٪ لأي تغيير: لا تقم بإجراء التغيير. المكون الإضافي الذي يعطل Gutenberg متاح بالفعل.
• المحرر متوافق بالفعل مع عدد كبير من مواقع الويب. ولكن مثل أي شيء آخر ، عندما ينكسر ، يكون دائمًا أكثر وضوحًا.

من المستحيل أن تكون متوافقًا بنسبة 100٪ مع مواقع الويب الموجودة

الآن بعد أن أصبح هذا واضحًا ، دعنا نبني المحرر الذي نعتقد أنه الأفضل لمستقبل WordPress من فضلك.

هل يجب أن تعمل جميع أجهزة التمثيل الغذائي على الهاتف المحمول؟

نعم ، لماذا لا يفعلون ذلك؟

ما هي الحالات (إن وجدت) التي لن يتم تحويلها إلى كتل؟

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

بالنسبة لأشياء مثل أنواع المنشورات المخصصة ، التي قد تتكون من مربعات وصفية فقط ، أجد صعوبة في فهم واجهة المستخدم الجديدة. نظرًا لأن WordPress يفتقر إلى واجهة برمجة تطبيقات CRUD شاملة للبيانات ، فإن الكثير من المطورين يستخدمون WP_Query ومجموعة واجهات برمجة التطبيقات ذات الصلة كإجراء احتياطي ، ويستخدمون مربعات التعريف على شاشات تحرير CPT لعزل واجهة المستخدم لإضافة بيانات محددة أو ذات الصلة. العديد (غالبية) أنواع المنشورات المخصصة في البرية تزيل التركيز أو تتجاهل الاستخدام التقليدي "للمحتوى" - لذلك بالنسبة لمنشورات المدونة ، نعم ، المحتوى في المقدمة وفي المنتصف ، ولكن بالنسبة للعديد من حالات استخدام CMS ، لا تجعل WYSIWYG الكثير من المعنى.

في هذا التكرار الحالي ، يعد دعم Meta Box وظيفة إضافية ، عندما تكون Meta Boxes في واقع العديد من الأشخاص هي واجهة المستخدم وواجهة برمجة التطبيقات والآلية التي يستخدمونها لإنشاء نظام إدارة المحتوى الخاص بهم. <iframe> s هي الجولاج.

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

سأختتم بهذا المثال: إذا كان أحد مربعات التعريف "القديمة" الخاصة بي يقوم بتشغيل واجهة المستخدم لوسائط لفتح ، فكيف سيعمل ذلك في هذا السيناريو "الجديد" ، من داخل إطار iframe ، بدون شخص (عميل لم أعد أعمل معه ) إعادة كتابة الكود؟

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

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

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

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

أعتقد أنه قد يكون من الخطأ تأجيل هذا الأمر إلى حد بعيد. خاصة وأن العديد من المنظمات ستحتاج على الأقل 1-2 ربع للتحضير.

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

من المستحيل أن تكون متوافقًا بنسبة 100٪ مع مواقع الويب الموجودة

إذا كنت لن تكون متوافقًا ، فاحرص على كسر الأشياء. اتصل بالإصدار الأول WP ++ أو WPNG. من الأفضل بكثير أن نعلن مقدمًا أن الأشياء ستنكسر على الأرجح وأن تترك الناس يستعدون لها. إن "الخداع" الحالي وكأن الأمور ستسير كالمعتاد هو أمر سيء للجميع.

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

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

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

اقتراحي المثمر ، هو عدم إعلان أن مربع التعريف جاهز

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

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

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

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

إن جعل هذا المسار إلى الأمام سلسًا قدر الإمكان هو ضرورة مطلقة.

متفق عليه

سيؤدي هذا إلى كسر الأشياء ، وهذا أمر جيد (هناك فواصل في التوافق الخلفي تقريبًا في كل إصدار من WordPress) ، لكن يجب تصغيرها وتوثيقها ونقلها.

متفق عليه

من المستحيل أن تكون متوافقًا بنسبة 100٪ مع مواقع الويب الخارجة بغض النظر عن الخيار الذي تختاره للمحرر لأن المكونات الإضافية لها وصول كامل إلى DOM ، وأي شيء تقوم بتعديله في dom يكسر التوافق إلى الوراء

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

أعتقد أن كل هذا تجربة ، أعتقد أن kevinwhoffman يفعل ذلك أيضًا. أرى أن هذه المسألة _تقييم مدروس _ لهذه التجربة ويجب أن تؤخذ على هذا النحو. هل تكفي هذه التجربة كحل نهائي؟ رقم إذن ما هي التجربة التالية؟

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

tldr. هل نتوقع كسر مع جوتنبرج؟ نعم! ولكن لا يزال يتعين علينا أن نكون انتقائيين فيما يتعلق بـ "ما" نكسر ، وإلى أي مدى يذهب هذا الكسر في التكرار الأولي لـ Gutenberg المندمج في النواة.

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

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

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

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

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

أنا أؤيد بشدة وجهة نظر يوست عن جوتنبرج. لم يتضح لي كيف تمت إعادة تفسير عبارة "ترقية المحرر المرئي" على أنها "استبدال واجهة تحرير المنشور بالكامل" من قبل فريق Gutenberg ، ولكن يبدو أنها تتعارض بشكل مباشر مع ما يسمى بـ "سفينة ثيسيوس".

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

aaronjorbin حسنًا ، يبدو أن هناك مشكلة اتصال هنا كما في https://make.wordpress.org/core/2017/10/24/whats-new-in-gutenberg-24th-october/ قيل صراحة

يتضمن هذا الإصدار دعم صناديق التعريف الذي طال انتظاره (يحتاج إلى اختبار!) ،

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

بالعودة إلى الموضوع ، أرى أن المشكلة الرئيسية هنا هي محاولة تجنب إعلان الكسر. من خلال فهمي المحدود لـ JS Framewoks ، من الصعب جدًا أن تكون "نصف حامل" معهم ، وبمجرد أن تقرر أن التحكم في الشاشة الرئيسية يتم معهم ، يجب فعل كل شيء معهم ، وبالتالي فإن الطريقة الوحيدة للمضي قدمًا هي اجعل مربعات التعريف مواطنين من الدرجة الأولى في شاشة تحرير جوتنبرج.
نظرًا لأنه من غير المحتمل أن تتكيف المكونات الإضافية "القديمة" ، فإن هذا يعني أن gutenberg يحتاج إلى أن يكون خيار تمكين صريحًا للمواقع الحالية. أنا أكره فكرة UX fork ، ولكن على الأقل بهذه الطريقة ستكون هناك طريقة للمضي قدمًا ، وإذا تم الإعلان عنها الآن فسيكون الناس قادرين على الاستعداد.

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

يمكن إضافة عدد جديد واحد مع إطارات iframe هذه. عندما تخرج جلسة المستخدم ، تظهر شاشة تسجيل الدخول إلى WP فوق Gutenberg ، وداخل iframe مرتين.

فقط للمطورين ليكونوا على دراية بذلك.

أكثر أنا أتابع كل هذا أكثر أنا مقتنع بأن الطريقة الممكنة فقط ستكون كما فعلت مايكروسوفت.

Windows XP = WordPress بدون Gutenberg
Windows 10 = Wordpress مع Gutenberg.

لا يمكن خلط هذين الرقمين وتحديثهما مع حزم أخرى.

فعلها جوملا ودروبال. لما لا. ليس شيئًا أفضله على الإطلاق ، ولكن ما هو البديل.

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

سيكون المشرف المنفصل أحد أسوأ النتائج التي يمكن أن تأتي من Gutenberg. لقد أوجزت الأسباب في https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341752490.

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

كيفين هوفمان:

أنا أتفق بشدة مع هذا المفهوم الذي طرحه Yoast ، والذي يبدو لي أنه سيحافظ على الكثير من العمل المنجز بالفعل مع تقليص نطاق المشروع للتركيز على مكون المحرر. المصدر: https://yoast.com/gutenberg-alternative-approach/

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

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

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

من فضلك ، كن منفتح الذهن ، ولنبدأ بالإجابة على بعض الأسئلة:

ما هو هدف جوتنبرج؟

لم يكن الهدف الرئيسي لجوتنبرج ، ولم يكن كذلك أبدًا ، هو تمهيد الطريق لمستقبل WordPress Core. من الناحية الفنية ، من خلال الاستفادة من واجهة برمجة تطبيقات REST وواجهة المستخدم من جانب العميل وتوحيد المفاهيم الأساسية: الأدوات ، والرموز القصيرة ، والكتل ، و Metaboxes تحت مفهوم فريد "A Block" والتجربة الحكيمة من خلال الإجابة على هذه الأسئلة: كيف يمكن تبسيط بناء مواقع الويب (التفكير في التخصيصات) ونشر المحتوى (محرر التفكير) في WordPress.

ما هو هدف محرر جوتنبرج؟

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

ماذا عن Metaboxes ، هل هي مهمة لـ WordPress؟

هم انهم. مثل الرموز القصيرة ، أزرار مخصصة TinyMCE ، يتم استخدامها بشكل كبير وإساءة استخدامها لتوسيع صفحة محرر WordPress.

ما الفرق بين الرموز القصيرة وأزرار TinyMCE و Metaboxes؟

الاختلاف الرئيسي هو أن "Metaboxes" ليس لها "غرض" ، إنها مجرد وسيلة لتوسيع صفحة المحرر بدون تناسق بينما يكون للأزرار القصيرة و TinyMCE واحدة.

الرموز القصيرة عبارة عن سلسلة تم تحويلها إلى محتوى في مرحلة العرض ، وأزرار TinyMCE عبارة عن أزرار مخصصة تمت إضافتها إلى شريط أدوات TinyMCE وتستخدم TinyMCE API للتواصل مع محتوى المحرر. Metaboxes؟ لا أعرف ، يمكن أن يكونوا أي شيء ، ما عليك سوى إضافة مجموعة من HTML و Javascript و PHP لتوسيع صفحة المحرر وكيف تتصرف عند الحفظ.

هل هذا النقص في "الغرض" مشكلة أم ميزة؟

حسنا! يمكن اعتباره "محترفًا" ، لأن المكون الإضافي يمكنه فعل أي شيء يريده مع المحرر بما في ذلك أشياء مثل:

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

حق مرن! ولكن ماذا عن تحديثات WordPress. أي تحديث لشاشة المحرر. أي تحديث لـ TinyMCE ، أي تغيير في الفصل ، أي جديد div ، أي زر تمت إزالته / نقله ، أي تغيير يكسر التوافق مع المكونات الإضافية لأنك بصفتك مطورًا لـ Core WordPress ، لا تعرف ما هي المكونات الإضافية التي تستخدم Metaboxes.

هل يمكننا أن نستنتج أنه على المدى الطويل لـ WordPress ، فإن Metaboxes تقفل تطورها (بغض النظر عن Gutenberg)؟

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

حسنًا ، ولكن كيف يمكننا المضي قدمًا في WordPress إذا كنا عالقين في Metaboxes؟

هذا سؤال جيد وقبل الإجابة ، نحتاج إلى فهم الاستخدام الحالي لـ Metaboxes في مكونات WordPress الإضافية

لماذا تستخدم المكونات الإضافية الحالية Metaboxes؟

أود أن أقول إن هناك فئتين من المكونات الإضافية "Metaboxes":

• Metaboxes كمحتوى (غالبًا ما يتم تخزينه في مرحلة ما بعد التعريف ولكن ليس دائمًا)
• Metaboxes كتحسين لتجربة المحرر (SEO ، التدقيق الإملائي ، ...)

حسنًا ، مع العلم بهذا ، كيف يمكننا المضي قدمًا؟

نحتاج إلى ثلاثة أشياء:

• وفر طريقة لإنشاء هذه المكونات الإضافية أو ترقيتها أثناء شحن Gutenberg (أو أي تحديث لـ WordPress).
• قم بتوفير أفضل مسارات الترقية الممكنة للأشخاص الذين يستخدمون هذه المكونات الإضافية. يتضمن ذلك: معرفة ما إذا كان لا يزال بإمكان هذه المكونات الإضافية العمل مع التطورات القادمة وكيفية تقليل الكسر.

حسنًا ، لكن ألم تقل أن أي تغيير في صفحة المحرر سيؤدي إلى تعطيل المكونات الإضافية (بما في ذلك استبدال منطقة المحتوى فقط)؟

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

لن أسمي هذا مسارًا جيدًا للترقية شخصيًا ، فهو ليس ترقية حتى ، أي شيء أفضل؟

يعد مسار الترقية هذا (تعطيل Gutenberg) ضرورة ولكن نعم ، يمكننا أن نفعل ما هو أفضل. إذا ألقيت نظرة على المكونات الإضافية التي تستخدم Metaboxes ، فإن 90٪ منها ليس لديها أي تفاعل مع منطقة المحتوى ، وبالتالي ، إذا استبدلنا منطقة المحتوى فقط (نهج yoast) ، فسنقوم بكسر 10٪ من المكونات الإضافية فقط.

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

تتكون تجربة مستخدم Gutenberg المثلى من استبدال المكونات الإضافية لصناديق التعريف بمكونات إضافية توفر نفس الوظائف مع واجهات برمجة تطبيقات Gutenberg Extensibility الجديدة.

ومع ذلك ، لاحظنا أن معظم المكونات الإضافية التي تستخدم Metaboxes تستخدمها كمحتوى يتم حفظه لنشر meta ويمكننا جعلها تعمل في شاشة Gutenberg للاستمتاع بالتجربة بأكملها بينما يقوم مؤلفو المكونات الإضافية بترقية المكونات الإضافية الخاصة بهم.

هل هذا هو حل iframe الذي يتحدث عنه الجميع؟

نعم إنه كذلك. نعرض المربعات الوصفية في إطارات iframes التي لها عيوبها (رابط ، مشروط ، إعادة تحميل الأصول) ولكنها في نفس الوقت تسمح لـ 80٪ من المكونات الإضافية بالعمل أثناء الاستمتاع بتجربة Gutenberg بأكملها. لقد وصل هذا الحل للتو وما زلنا نجربه. ما هو مؤكد هو أنه لا توجد طريقة لجعل جميع مربعات التعريف تعمل وإجراء تغييرات على المحرر.

أرى ، هل يمكنك تلخيص إمكانيات الترقية من فضلك؟

بالتأكيد.

1- قم بتعطيل Gutenberg: لا تقم بكسر 100٪ من الملحقات
2- يستبدل Gutenberg منطقة المحتوى فقط: تعمل 90٪ من الإضافات ، وتعاني UX
3- يستبدل Gutenberg الشاشة بأكملها: 80٪ من الإضافات تعمل ، UX أفضل
4- Gutenberg مع ملحقات متوافقة: أفضل تجربة مستخدم ممكنة

إذن ماذا علينا أن نفعل؟

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

كيف يمكنني الاشتراك في خيار على خيار آخر؟

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

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

نحن جميعًا على نفس القارب ، نريد الأفضل لـ WordPress.

شروحات دقيقة للغاية ، رياض. شكرا لتخصيص الوقت لكتابتها. اسمح لي بمساعدتك في البقاء بعيدًا عن هذا الحد باستخدام و 🤗. آمل أن يساعد.

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

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

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

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

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

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

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

الاختلاف الرئيسي هو أن "Metaboxes" ليس لها "غرض" ، إنها مجرد وسيلة لتوسيع صفحة المحرر بدون تناسق بينما يكون للأزرار القصيرة و TinyMCE واحدة.

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

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

أي تحديث لشاشة المحرر. أي تحديث لـ TinyMCE ، أي تغيير في الفصل ، أي div جديد ، أي زر تمت إزالته / نقله ، أي تغيير يكسر التوافق مع المكونات الإضافية لأنك بصفتك مطورًا لـ Core WordPress ، لا تعرف ما هي المكونات الإضافية التي تستخدم Metaboxes من أجلها.

قد لا نعرف الغرض من meta box ، لكننا نعرف المتطلبات الأساسية لتسجيل Meta box والخطافات التي يستخدمونها. نحن نعلم أنه لم يتم تطوير أي منها للعمل ضمن إطارات iframe. لقد فهمنا لسنوات كيفية توسيع وتحسين WordPress دون كسرها. مرة أخرى ، إذا كان الإصدار 5.0 مجرد إصدار WordPress آخر ، فلا ينبغي أن يختلف مقدار الكسر عن أي إصدار آخر.

نعرض المربعات الوصفية في إطارات iframes التي لها عيوبها (رابط ، مشروط ، إعادة تحميل الأصول) ولكنها في نفس الوقت تسمح لـ 80٪ من المكونات الإضافية بالعمل أثناء الاستمتاع بتجربة Gutenberg بأكملها.

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

من فضلك توقف وأعد التقييم الآن ، وليس لاحقًا

بعد كل هذه المناقشة وما اعتقدت أنه دليل على أن إطارات iframe ليست حلاً قابلاً للتطبيق على المدى الطويل ، صادفت https://github.com/WordPress/gutenberg/issues/3165#issuecomment -341476059 الذي يتطلع إلى إضافة ثالث iframe إلى جوتنبرج.

لقد حان الوقت للتوقف عن متابعة المحرر المثالي كما لو أن القيود غير موجودة ، والبدء في التفكير في نهج لا يكسر WordPress.

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

أولاً ، كان الناس يطرحون مشكلة الأيض منذ اليوم الأول ، إلى جانب العديد من المشكلات الأخرى التي لا تزال معلقة في الهواء. في مرحلة Mockup ، قيل لنا "كل شيء هو أفضل حالة بصرية ، وسنعالج المربعات لاحقًا". بعد ذلك ، في مرحلة النموذج الأولي ، كان "هذا دليل على كود المفهوم ، سيتم التعامل مع صناديق التمثيل الغذائي لاحقًا". ثم عندما تم إصدار التكرار الأول للمكوِّن الإضافي للميزات (والذي كان مفاجأة كبيرة لأي شخص ، وليس إعادة كتابة من الصفر بعد كل شيء ، ومجرد إعادة تجميع لإثبات كود المفهوم الحالي) ، أصبحت الحجة فجأة "واجهات قديمة مثل صناديق التعريف سيكون لها بعض الدعم في الوقت الحالي". بعد ذلك ، عندما صمت الصرخة العامة آذانًا ، كانت "أخطأنا في التنبيه ، فالأيض ليست إرثًا". لكن الآن ، هذه الحجة تدفع فقط بجدول الأعمال "الإرث" مرة أخرى.

Metaboxes ليست رمزًا قديمًا ، لأنه لا يوجد حاليًا بديل قابل للتطبيق.

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

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

فيما يلي خارطة طريق لخطة "الإدارة الموحدة" لجوتنبرج والتي ستعمل بالفعل:

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

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

بحلول الوقت الذي يتم فيه إهمال عمليات التمثيل الغذائي ، سيكون لدى مؤلفي البرنامج المساعد الوقت الكافي لتعلم واستخدام فوائد Gutenberg في البرية ، وسيكون هذا هو الخيار الواضح.

جوتنبرج مثل مفهوم السيارة. قم بالرجوع الآن ، وقم بشحن تحسين تكراري إلى المحرر (وليس صفحة المحرر). بعد ذلك ، خلال العام أو العامين المقبلين ، يمكنك السير في المشروع نحو تغطية إدارية بنسبة 100٪.

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

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

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

من الممكن (وربما من المحتمل أيضًا) أن يتم تحديث مكونات Meta box الإضافية التي استخدمتها على مواقع العملاء لتكون "متوافقة مع Gutenberg" ولكن حتى ذلك الحين سيتغير سير العمل بأكمله لهؤلاء العملاء بين عشية وضحاها. يبدو الأمر كما لو أنه يسأل الكثير من هؤلاء العملاء عندما يكون سير العمل الحالي جيدًا بالنسبة لهم منذ أن تم تسليم موقعهم ولكن منذ فترة طويلة.

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

فقط سنتان ، أتطلع إلى مراقبة النتيجة هنا.

قد يكون عدد المكونات الإضافية التي تعمل مع Gutenberg 80٪ أو 90٪ أو 0٪ كما هو الحال في اختباراتنا ، ما يجب تجنبه هو أن الآلاف والآلاف من مالكي المواقع يجب أن يكتشفوا بأنفسهم ما إذا كان التكوين الخاص بهم سيعمل على الأرجح أم لا مع جوتنبرج. سيكون هذا مضيعة هائلة للوقت (= المال) ، ويسبب الكثير من الارتباك ويقتل الكثير من الثقة.

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

أدرك أن هذا لن يكتمل أبدًا أو دقيقًا بنسبة 100٪ ، ولكن يجب أن يكون ممكنًا بالنسبة لأبرز المكونات الإضافية.

ملاحظة.
بالنسبة لمشاريعي الخاصة (نظام أساسي لمواقع الإنترنت الصغيرة لعميل أكثر من 30.000 موظف ، ومجموعة من الشركات الصغيرة / المواقع غير الربحية) قررنا تعطيل Gutenberg حتى يمر عام واحد على الأقل بنجاح في البرية.

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

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

ما لا أفهمه هو الرغبة في الانتقال من 0 إلى 100 دفعة واحدة. لماذا لا يكون الإصدار التكراري هو المسار المتبع هنا؟ لماذا الخياران "لا يكسر أي شيء" أو "يكسر كل شيء"؟

Metaboxes هي السبب في أن WordPress قوي كما هو. الغرض منه هو تمديد شاشة التحرير.

أعتقد أنه من الرائع أن Gutenberg يريد إصلاح الشاشة بأكملها ، لكنني لا أعتقد أنه من الواقعي القيام به دفعة واحدة ، خاصة إذا كان ذلك يعني معالجة أحد أهم مكونات WordPress (فيما يتعلق بالتطوير المخصص ... يعد جزءًا كبيرًا من نجاح WordPress) جانباً.

2- يستبدل Gutenberg منطقة المحتوى فقط: تعمل 90٪ من الإضافات ، وتعاني UX

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

4- Gutenberg مع ملحقات متوافقة: أفضل تجربة مستخدم ممكنة

هذا هدف ممتاز ، لكنه هدف بعيد المدى. في النهاية ، نعم ، بالتأكيد ، يجب أن يكون Gutenberg مع المكونات الإضافية التي تعمل جنبًا إلى جنب مع تجربة Guteneberg أو داخلها.

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

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

تعجبني خارطة الطريق التي اقترحها gschoppe ، بصفتي مطورًا يقوم بإنشاء مواقع WordPress مخصصة ، فهذه طريقة يمكنني أن

إلى جانب مخاوف كيفن بشأن إطارات iframe ، أود الإشارة إلى بعض المخاوف المتعلقة بإمكانية الوصول. أولاً ، في حين أن المستخدمين الذين يواجهون موقعًا بصريًا سيختبرون مجموعات الإطارات وإطارات iframes ككل متماسك مع بقية الصفحة ، فإن مستخدمي قارئ الشاشة لا يفعلون ذلك. يختبر مستخدمو قارئ الشاشة كل إطار داخل مجموعة إطارات ، وكل إطار iframe ، كجزء مميز ، منفصل عن بقية الصفحة ، لأن صفحات الويب تتم تجربتها بطريقة خطية. تحتوي بعض برامج قراءة الشاشة ، (لا سيما Jaws for Windows ، وهي الأكثر حصة في السوق وفقًا لاستبيان استخدام قارئ الشاشة السنوي لـ WEBAIM) ، على إعداد تكوين لتجاهل الإطارات ، بما في ذلك الإطارات المضمنة ، لأنها يمكن أن تتعارض مع بعض الشاشات مستخدمي القارئ. عندما يتم استدعاء إعداد تجاهل الإطارات ، يختفي المحتوى داخل الإطارات وإطارات iframes. حتى إذا اتبع Gutenberg أفضل ممارسات الوصول عندما يتعلق الأمر بإطارات iframe ، فإن مطالبة المستخدمين بتعطيل هذا الإعداد من أجل التمكن من تحرير المحتوى بالكامل يعرضهم أيضًا لكل مثيل iframe وإطار أسوأ ممارسة على الشبكة. البديل الوحيد الآخر لهؤلاء المستخدمين هو مطالبتهم بإنشاء ملف تعريف منفصل فقط لاستخدام Gutenberg ، وهي ليست عملية بسيطة ، لأنها تعني أنهم بحاجة إلى تكوين كل إعداد للمتصفح وإعداد الكلام مرة أخرى. وهذا يعني أيضًا أنهم بحاجة إلى متابعة ملفي تعريف مستعرضين منفصلين على الأقل. سأكون أول شخص يخبر Jaws لمستخدمي Windows بالانتقال إلى NVDA بدوام كامل لأسباب. استخدام جوتنبرج لإطارات iframe لدعم التمثيل الغذائي ليس أحد هذه الأسباب.

.. صبري بصفتي مطورًا بسيطًا قضى العام بأكمله في التفكير في أفضل طريقة ممكنة للمضي قدمًا في WordPress ككل (الأساسي والمجتمع) قريب من الحد الأقصى.

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

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

أعترف أننا في بعض الأحيان (على الأقل أنا) يمكن أن نكون رافضين في تعليقاتي وأنا أعتذر عن ذلك.

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

يحزنني أن أكتب هذا ولكنني لن أقترح بعد مليون عام أن يبدأ أي شخص مشروعًا كبيرًا باستخدام WordPress الآن.

2- يستبدل Gutenberg منطقة المحتوى فقط: تعمل 90٪ من الإضافات ، وتعاني UX

youknowriad ، كيف يمكنك القول أن UX لا يعاني من Gutenberg مقابل TinyMCE؟ أنا بصدق أطرح هذا السؤال ، لا أشخر. أستطيع أن أخبرك أن UX تعاني بالفعل بشكل كبير في Gutenberg مقارنةً بـ TinyMCE و meta box. أود أن أشجعك على اكتشاف ذلك بنفسك من خلال:

(1) فصل الفأرة عن الكهرباء.
(2) إذا كنت تستخدم جهاز Mack ، فاضغط على command + f5 وحاول إنجاز أي شيء مثمر باستخدام VoiceOver.
(3) إذا كنت تستخدم جهاز كمبيوتر ، فقم بتنزيل NVDA وتثبيته وفصل الماوس وقم بإجراء نفس الاختبار. حاول أن تفعل شيئًا مثمرًا مع Gutenberg في ظل هذه الظروف.

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

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

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

1. المصدر المفتوح. أعتقد أن هذا الجمهور يمكن أن يتفق على مدى قوة وفائدة ذلك.
2. سهولة الاستعمال. جعل WordPress من السهل بشكل مثير للدهشة على غير المطورين إنشاء المحتوى وتحديثه. كان هذا ضخمًا في سنواتي الأولى من إنشاء مواقع الويب للأفراد والشركات.
3. تعريف المحتوى. أنواع المنشورات المخصصة والتصنيفات المخصصة ومربعات التعريف المخصصة. عندما وصل كل شيء يؤدي إلى هذه الأشياء إلى حالة فردية ، لا أعتقد أنني وصلت عندما أقول إن هذا كان عندما كان WordPress "قابلاً للبيع" لمجتمع الأعمال باعتباره أكثر من مجرد برنامج مدونة. (WordCamp Phoenix 2012 - CMB. كتابات Justin Tadlock الرائعة حول تحديد أنواع المنشورات والتصنيفات ومربعات التعريف.)

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

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

@ jchristopher يقول ذلك جيدًا:

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

يقدمjnicol و aurooba نقاطًا رائعة amandarush ، لاستدعاء مشاكل إمكانية الوصول. أتحدى الجميع أن يحاولوا العمل مع جوتنبرج بالطريقة التي أوضحتها. قد يغير بعض وجهات النظر.

قال @ aaronjorbin في وقت سابق ، عندما

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

كان WordPress هو الحل الأفضل لملايين المواقع: سهولة الاستخدام والمصدر المفتوح هو المفتاح. كسر المربعات الوصفية المخصصة (هل نسيت أرقام البرنامج المساعد ، ماذا عن جميع مواقع الويب الحالية ذات واجهات المستخدم المخصصة للمشرف؟) مع التنفيذ السريع لواجهة محرر جديدة تتسبب في أضرار سهلة الاستخدام.

صبري بصفتي مطورًا بسيطًا قضى العام بأكمله في التفكير في أفضل طريقة ممكنة للمضي قدمًا في WordPress ككل (الأساسي والمجتمع) قريب من الحد الأقصى.

سأكون صريحًا ، هنا:

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

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

بدلاً من ذلك (وهذا سيكون أفضل بكثير) ، خذ هذه الأفكار. فكر حقًا في ما يقوله الناس. افهم مخاوفنا كأشخاص يديرون أعمالًا تستخدم WordPress وتفهم أننا لا نهتم بأنفسنا فحسب ، بل بعملائنا.

لقد كنت أستخدم WP منذ أوائل عام 2008 ، ولا يمكنني التفكير في ميزة أو قرار جديد أوجد الكثير من الانقسامات في كل ذلك الوقت مثل تقديم Gutenberg ، في شكله الحالي.

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

أرى إشارات إلى الرغبة في تلبية احتياجات مستخدمي التثبيت الجديد (ما؟ حوالي 1٪ زيادة الويب سنويًا؟) ، ولكن يبدو أن هذا على حساب قاعدة المستخدمين الحالية (حوالي 28٪) ، من المحتمل أن يقوم معظمها بتشغيل مكون إضافي يحتوي على مربع تعريف واحد على الأقل. هذا يبدو وكأنه منطق تجاري ضعيف على أي نطاق.

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

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

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

هذا يعني أن هناك طرفًا واحدًا يحتاج إلى التراجع - وسواء أكان هناك 10-50 مطورًا مؤيدًا لـ Gutenberg ، أو مئات / آلاف المطورين الذين يشعرون بالخوف أو التأثير الذي ستحدثه التغييرات عليهم ، ناهيك عن مستخدميهم ، سنرى.

بمجرد استنفاد جميع اقتراحات الحلول البديلة ، فربما يكون هناك تنازل يفيد بأن تجاوز الصفحة بأكملها غير ممكن لجميع الأطراف. على الأقل ليس في النتيجة الواحدة التي تتم تجربتها حاليًا.

للعودة إلى السؤال الأصلي - هل إطارات iframe هي الحل طويل الأمد لمربعات التعريف؟ شرح العديد من المطورين (ودعنا لا ننسى ، فهم مستخدمون أيضًا) سبب عدم الإجابة.

لقد أجرينا مناقشة بناءة إلى حد كبير هنا. تذكر:

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

اسمحوا لي أن أذكر الجميع أن المستقلبات في جوتنبرج كانت نتيجة تصعيد @ BE-Webdesign وتنفيذ ذلك ، بشكل مستقل عن أي شخص آخر مع القليل من المساعدة ، وظهر من العدم. إذا لم يكن لـ @ BE-Webdesign ، فلن يكون هناك مربعات تعريف في Gutenberg. من بين 47 تعليقًا تركت هنا ، ربما قام شخصان فقط بالتطرق بالفعل إلى رمز الاستقلاب للمراجعة ولأغراض تجربة المستخدم.

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

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

اقتراحي هو:

بدلاً من تحميل Gutenberg على صفحة إعدادات ، دعنا نحمّله في صفحة المحررين الكلاسيكية الرئيسية ، ونحمّل مربعات التعريف في بيئتهم الأصلية ، ثم ارفع عقدة DOM الحاوية إلى مكون عبر JS

ثم نستخدم نوعًا مختلفًا من التبديل للتأكد من استمرار إمكانية استخدام المحرر الكلاسيكي. من هنا:

• نتجنب هراء iframe
• تعمل صناديق التمثيل الغذائي كما فعلت دائمًا فيما يتعلق بالتسجيل
• تعمل JS الحالية كما هو متوقع ، ولا توجد عمليات اختراق ضرورية لجعل الأشياء تعمل في نهاية PHP

أيضًا ، تصميم yoast جميل ، ولكن أين تذهب كتلة meta؟

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

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

اسمحوا لي أن أذكر الجميع أن المستقلبات في جوتنبرج كانت نتيجة تصعيد @ BE-Webdesign وتنفيذ ذلك ، بشكل مستقل عن أي شخص آخر مع القليل من المساعدة ، وظهر من العدم. إذا لم يكن لـ @ BE-Webdesign ، فلن يكون هناك مربعات تعريف في Gutenberg.

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

اقتراحي هو:

بدلاً من تحميل Gutenberg على صفحة الإعدادات ، دعنا نحمّله في صفحة المحررين الكلاسيكية الرئيسية ، ونحمّل> صناديق التعريف في بيئتهم الأصلية ، ثم ارفع عقدة DOM الحاوية إلى مكون عبر JS

نعم ، هذا هو التكرار التالي على الأرجح ، وأعتقد أن هذا اقتراح رائع بالإضافة إلى فكرة بناءة. لست متأكدًا بنسبة 100٪ من كيفية القيام بذلك بشكل نظيف حتى الآن ، ولكن من الممكن تمامًا عدم استخدام إطارات iframe ، والحصول على نفس تجربة المستخدم المحسنة التي يوفرها Gutenberg بالفعل. ستكون هناك تحديثات قادمة لتحسين تجربة meta box ، والتي من المحتمل أن تتضمن إزالة iframes. لقد عملت طريقة iframe كطريقة لمعرفة كيف يمكن تنفيذ دعم meta box ، والآن سيتم إجراء تحسينات أفضل. عندما تم استكشاف الأشياء لأول مرة باستخدام مربعات التعريف منذ عدة أشهر (ليس موضوعًا جديدًا) ، كان من المنطقي المضي قدمًا في نهج iframe ، نظرًا لحالة Gutenberg في ذلك الوقت ، والآن بعد أن تم دمجها وتحريك العديد من القطع الأخرى حولها ، ربما لم يعد استخدام إطارات iframe ضروريًا من وجهة نظر فنية. يجب القيام بالمزيد من العمل.

@ BE-Webdesign نشكرك على جهودك ومساهمتك هنا. دعنا نغلق هذا ونبدأ مشكلة جديدة عندما يكون هذا النهج جاهزًا للمناقشة.

من فضلك توقف وأعد التقييم الآن ، وليس لاحقًا

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

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

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

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

mtias أقدر حقًا تعليقك المعقول ، خاصة الجزء المتعلق بـ "WordPress يتحرك دائمًا مع المستخدم".

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

لسوء الحظ ، لم تتناول مخطط Yoast المقترح والذي من شأنه أن يمنحنا كل مرونة Gutenberg بينما يكون متوافقًا مع مربعات التعريف الحالية. لماذا لا يستطيع أحد أن يعترف لماذا لا تفكر في هذا النهج؟

لسوء الحظ ، يتعارض هذا تمامًا مع ما يتواصلyouknowriad في هذا الموضوع

أعتقد أنك أساءت فهم ما قلته للتو ، كنت أعدد الحقائق فقط وأشارك mtias الأفكار بنسبة 100٪

تضمين التغريدة

ما أطلق عليه بعض الأشخاص على أنه نهج عملي لا يتزامن مع اتجاه التصميم الذي اتخذه هذا المشروع منذ البداية - التوجه نحو تخصيص الموقع بالكامل

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

من خلال إجراء هذا الانتقال الوسيط بسلاسة ، ستجعل من الأسهل بكثير إهمال إنشاء / معالجة DOM المباشر على شاشة post_edit ، لأنه بحلول ذلك الوقت ، لن يتضمن الحل القياسي العملي مثل هذا التلاعب. لا أعتقد أن أي شخص يقول "يجب أن تكون المعالجة المباشرة لعناصر DOM هي التجربة الأساسية إلى الأبد". يقولون "إنه الحل الأساسي الآن".

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

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

إنه لا يمثل خيانة لأهداف المشروع ، بل مجرد معالجة جدول الإصدار لجعل التغيير أكثر قابلية للإدارة لآلاف الوكالات والمطورين.

youknowriad اسمح لي بنشر بعض المقتطفات مما كتبته لدعم ما أقوله:

من خلال الاستفادة من واجهة برمجة تطبيقات REST وواجهة المستخدم من جانب العميل وتوحيد المفاهيم الأساسية: الأدوات ، والأكواد القصيرة ، والكتل ، و Metaboxes ضمن مفهوم فريد "A Block"

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

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

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

ما الفرق بين الرموز القصيرة وأزرار TinyMCE و Metaboxes؟
الاختلاف الرئيسي هو أن "Metaboxes" ليس لها "غرض" ، إنها مجرد وسيلة لتوسيع صفحة المحرر بدون تناسق بينما يكون للأزرار القصيرة و TinyMCE واحدة.

هذا مفهوم خاطئ عملاق يجب أن يثير الدهشة داخل Automattic. (وآملmtias وm الاستماع). إنه ببساطة ليس صحيحًا وأنا أتساءل حقًا عن حكمك بعد هذا البيان.

هل يمكننا أن نستنتج أنه على المدى الطويل لـ WordPress ، فإن Metaboxes تقفل تطورها (بغض النظر عن Gutenberg)؟
نعم إنهم هم.

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

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

ليس لدي أي ثقة حرفيًا في أنه إذا كنت سأقوم بعمل علاقات عامة لتقليل Gutenberg ليكون مجرد مكون تحرير ، فسيتم النظر فيه من قبل فريق Gutenberg ، بسبب البيانات التي أدلى بها عدد قليل من الأفراد داخل Automattic.

mtias ،

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

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

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

هناك أشخاص يمكنهم الاستفادة من تجربة Gutenberg الافتراضية في الوقت الحالي.

إطلاقا. ولكن هناك أيضًا عدد أكبر بكثير ممن سيكون لديهم تجربة ضارة مع Gutenberg الافتراضي في الوقت الحالي.

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

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

من المهم أيضًا أن نتذكر أن الكثير من أولئك الذين يعملون على Gutenberg كانوا أعضاء في مجتمع WordPress من قبل ، وكانوا (لا يزالون) مساهمين أساسيين من قبل. نعم ، هذا يشمل نفسي. سأتحدث هنا بشكل شخصي للغاية ، بمجرد إجراء العلاقات العامة ، يرجى إعلامي وسألقي نظرة وأتأكد من أنه يحظى بنفس الاحترام الذي تتمتع به جميع المراجعات ، بغض النظر عن المكان الذي أتوا منه. من فضلك ، دعنا ننتقل من رؤية هذا المشروع على أنه مشروع "نحن ضدهم". إنه ليس كذلك ولدينا بعض المساهمين المذهلين غير الآليين هنا ، هذا البيان يفعل لهم خدمة dis-service.

تضمين التغريدة

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

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

من المفترض أن تكون الكتل بنية تحكم أساسية للموقع ، بغض النظر عن الواجهة أو التخزين.

• من المقرر أن تصبح الحاجيات كتل. هذا لا يعني أنها ستكون موجودة في المحرر وسيتم حفظها في post_content. هذا يعني ببساطة أنه سيتم التحكم فيها من خلال نظام تم إنشاؤه في إطار عمل JavaScript بواجهة برمجة تطبيقات واحدة مشتركة.
• من المقرر أن يتم استبدال أداة التخصيص بالكتل. من المحتمل أن تظل الواجهة (تقريبًا) كما هي ، ولكن سيتم التحكم في أقسام أداة التخصيص بواسطة نفس واجهة برمجة التطبيقات.
• من المقرر أن تصبح صفحة المكونات الإضافية ، ومحرر السمات ، ولوحة المعلومات نفسها ، كتلًا في النهاية. إذا كانت فكرة هذه الأقسام ، كما هي تمامًا ، من المستحيل تخيل إعادة إنشائها باستخدام واجهة برمجة تطبيقات مشتركة ، فمن المحتمل أن يكون لديك بعض المفاهيم الخاطئة المرتبطة بماهية الكتلة ، في لغة WordPress.

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

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

لا تكمن المشكلة في أن صناديق التعريف لا يمكن أن تكون كتلًا. تكمن المشكلة في أنه في الوقت الحالي ، هناك واجهات تم إنشاؤها في مربعات التعريف ، والتي لم يتم دعمها بعد في الكتل (سواء بواسطة WordPress أو جهات خارجية) ، وإعادة تنفيذ هذا العمل مهمة شاقة للمطورين ، خاصة وأن هذه الأدوات لم يتم إنشاؤها من واجهة برمجة تطبيقات مشتركة مثل واجهة برمجة تطبيقات الحقول المقترحة ، ولكن بالأحرى بطريقة hodge-podge تقوم بتعديل DOM للصفحة مباشرةً ، وتدرج الموارد في قائمة مخصصة وغير مُدارة.

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

أو إذا كنت تستخدم WooCommerce جنبًا إلى جنب مع أي مكون إضافي يحتوي على الإصدار الجديد من مكتبة Select2 Library ، فإن أحدهما أو الآخر سوف يكسر واجهة المسؤول لديك ، مع وجود خطأ JS فادح.

يمكن أن يحدث نفس الشيء إذا كان هناك مكونان إضافيان مختلفان يعتمدان على إصدارات مختلفة من إطار عمل CMB2.

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

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

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

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

بعد كل ما قيل ، ما زلت أؤيد بشدة الحل المؤقت المقترح من Yoast ، باعتباره أفضل طريقة في العالم الحقيقي للتحرك نحو واجهة مستخدم مشتركة نهائية. ما زلت منتقدًا ، بالطبع ، لكني أريد التأكد من أننا ننتقد الحقائق ، وليس سوء الفهم.

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

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

من الواضح أن فريق Gutenberg المرتبط بـ Automattic لا يتزحزح عن شبر واحد ويصرف كل الانتقادات.

ليس لدي أي ثقة حرفيًا في أنه إذا كنت سأقوم بعمل علاقات عامة لتقليل Gutenberg ليكون مجرد مكون تحرير ، فسيتم النظر فيه من قبل فريق Gutenberg ، بسبب البيانات التي أدلى بها عدد قليل من الأفراد داخل Automattic.

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

لا يقوم Automattic "بإصدار" أو "إنشاء" WordPress ، كما أن Gutenberg ليس منتجًا تلقائيًا

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

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

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

@ karmatosed

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

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

تضمين التغريدة

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

gschoppe أتمنى فقط أن تتم مناقشة "النقلة

لماذا لا يستطيع أحد أن يعترف لماذا لا تفكر في هذا النهج؟

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

ليس لدي أي ثقة حرفيًا في أنه إذا كنت سأقوم بعمل علاقات عامة لتقليل Gutenberg ليكون مجرد مكون تحرير ، فسيتم النظر فيه من قبل فريق Gutenberg ، بسبب البيانات التي أدلى بها عدد قليل من الأفراد داخل Automattic.

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

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

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

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

إطلاقا. ولكن هناك أيضًا عدد أكبر بكثير ممن سيكون لديهم تجربة ضارة مع Gutenberg الافتراضي في الوقت الحالي.

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

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

أنت من شركة Automattic يجب ألا تشكو من أننا لا نستطيع احترام عملك ، وأننا ندفعك كثيرًا.
ليس مقابل 7000 - 10.000 يورو راتب شهري تدفعه. سخيف. ليس الأمر كما لو كان الناس يشكون على WP Trac للمتطوعين المطورين.
إذا تسبب لك جوتنبرج في حدوث صداع ، فتحدث إلى رئيسك في العمل. لقد أعطاك مهمة مستحيلة للقيام بها.

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

لماذا حاولت تمرير حل "إطارات Iframes"؟
قلت لك ، أنت تعامل الناس مثل الأطفال. دعونا نجرب مع إطارات iframe ونرى ما إذا كان الناس سيصرخون كثيرًا أم لا. إذا كان هناك الكثير من الضوضاء نبتعد عن إطارات iframe.

عندما تم تنفيذ دعم meta box لأول مرة ، كان المحرر الجديد موجودًا على صفحة مشرف جديدة تمامًا ، وليس post.php ، تم تحميل المحرر بشكل مختلف ، وبشكل عام كان هناك العديد من القيود ، جزء من حل مشكلة meta box باستخدام iframes ، وأضاء البعض من تلك القيود ، التي لم تعد موجودة ، ونتيجة لذلك ، لن تحتاج مربعات التعريف على الأرجح إلى استخدام إطارات iframe بعد الآن.

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

StaggerLeee من فضلك كن محترمًا للجميع في هذا المشروع بغض النظر عن مكان عملهم. تمامًا كما تحب أن يعاملك شخص ما بشكل جيد ، افعل الشيء نفسه مع الآخرين.

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

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

أنت من شركة Automattic يجب ألا تشكو من أننا لا نستطيع احترام عملك ، وأننا ندفعك كثيرًا.
ليس مقابل 7000 - 10.000 يورو راتب شهري تدفعه. سخيف. ليس الأمر كما لو كان الناس يشكون على WP Trac للمتطوعين المطورين.
إذا تسبب لك جوتنبرج في حدوث صداع ، فتحدث إلى رئيسك في العمل. لقد أعطاك مهمة مستحيلة للقيام بها.

StaggerLeee أتمنى لو تلقيت هذا التلميح الكبير 😂 لكن Automattic ليست Google ، ويمكنني كسب المزيد في أي مكان آخر في عالم WP. وجودي هنا يأتي من ظهري تمامًا ، ولا يدفع لي مقابل أن أكون هنا ، ولا الكثير من الأشخاص الآخرين الذين يعملون على هذا الأمر. لقد دفعت في الواقع لإجراء مراجعات التعليمات البرمجية والمساعدة في إطلاق عملاء المؤسسة!

لذا ثق في أن الرسالة قد تم استلامها ، والدليل موجود في علامة التبويب طلبات السحب في الأعلى ، هذه ليست مؤامرة تلقائية لكسر الكود الخاص بك و p ** s قبالة عملائك (_ لا تنسى ، لدى Automattic عملاء يدفعون استخدام الأيض أيضا _)

بالنسبة لأولئك الذين ما زالوا مهتمين بإطارات iframe ، أقترح النظر هنا في طلب السحب هذا (https://github.com/WordPress/gutenberg/pull/3345) الذي يحاول التراجع عن إطارات iframe وتنفيذ اقتراحي المقدم سابقًا.

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