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

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

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

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

هناك بعض التحديات الكبيرة في إرسال مربعات التعريف التي تديرها PHP عبر JS و Ajax ، لا سيما في كيفية التعامل مع تحديث عملية عرض ملف التعريف لتعكس الحالة المحفوظة حديثًا: https://core.trac.wordpress.org/ticket/7756

أتساءل عما إذا كان تضمين ملف تعريف قديم عبر iframe يمكن أن يكون حلاً هنا ، حيث يكون iframe src شيئًا مثل /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings ولا يُخرج سوى مربع تعريف واحد في المستند.

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

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

• Yoast SEO: يوفر عددًا كبيرًا من الحقول ، والتي من المحتمل ألا تتناسب مع الشريط الجانبي - ربما يكون بها مربع تعريف للشريط الجانبي الذي يفتح نموذجًا لمزيد من الخيارات ، ولكن هذا يبدو وكأنه يعمل على تجاوز قيود غير ضرورية

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

• WooCommerce - يضيف مربعات تعريف لبيانات الطلبات والعناصر ، أثناء إزالة المحرر الرئيسي (خطة Woo لبناء واجهته المخصصة في النهاية ، لكنني أظن أن هذا بعيد المنال ، وستكون المكونات الإضافية الأخرى في وضع مماثل)

(أفترض أنه من المقرر أن يحل Guttenburg في النهاية محل طرق العرض post-new / post-edit.php الحالية ، بدلاً من أن يكون مجرد بديل؟)

Ha بفضل braders - Yoast UX-er يقوم بالتسجيل هنا بنفس السؤال :)

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

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

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

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

سيكون من الجيد إنشاء تذكرة منفصلة لـ! مع لقطات من نوع المنشور الحالي ، إذا كان لديك! ✨

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

+1 للوصول إلى WordPress VIP. هذه أيضًا مشكلة في سلسلة كاليبسو: https://github.com/Automattic/wp-calypso/issues/587

ميزة مهمة حقًا لأعلى السوق!

أتساءل عما إذا كان تضمين ملف تعريف قديم عبر iframe يمكن أن يكون حلاً هنا ، حيث يكون iframe src شيئًا مثل /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings ولا يُخرج سوى مربع تعريف واحد في المستند.

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

كنت أرغب في العمل كمطور للمكونات الإضافية وكشخص يستخدم WordPress كأداة للتجارة الإلكترونية بشكل أساسي. كما أخبرني beacusekevinwhoffman .

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

أنا أيضًا لست معجبًا كبيرًا بالحالة الحالية لمحرر WordPress و metabox-palooza. لقد عدت للتو وفي التنزيل (نوع منشور منتج Easy Digital Download) عرض منشور واحد ، لدي 14 صندوقًا تعريفًا مخصصًا تمت إضافته بواسطة Yoast ، والتنزيلات الرقمية السهلة والرمز المخصص الخاص بي باستخدام CMB2. إنه كثير ، لكني بحاجة إلى هؤلاء. WordPress لا طائل من ورائه بدون تلك الواجهة وما تعرضه.

أنا قلق من أن هذا لم يؤخذ في الاعتبار منذ البداية لأنني عملت على العديد من المواقع حيث كانت واجهة الحقول المخصصة المضافة مع ACF و Pods و CMB2 وما إلى ذلك تجربة التحرير بأكملها.

هذه هي مخاوفي الفنية:
1) تمت إضافة الأزرار عبر media_buttons. في المكوِّن الإضافي Caldera Forms الخاص بي (80K + تثبيتات نشطة) ، نستخدم هذا الإجراء لإضافة زر إدراج نموذج يُظهر نموذجًا لإدخال الرمز القصير في محرر النشر. ربما ننتقل إلى قالب مخصص في جوتنبرج.
2) كيف يظل إجراء save_post متوافقًا مع الإصدارات السابقة؟ يوجد الكثير من المكونات الإضافية والسمات وخطافات الشفرة المخصصة في save_action والوصول إلى $ _POST super global. هذا ليس تصميمًا جيدًا ، لكنه دين فني يؤثر على ملايين المواقع.
3) كان هناك اقتراح لتقديم مربعات التعريف القديمة في iFrame. هذا يقلقني لأن الوصول إلى محتوى iFrame عبر JavaScript غير ممكن.

@ Shelob9 مرحبا!

كان هناك اقتراح لتقديم مربعات التعريف القديمة في iFrame. هذا يقلقني لأن الوصول إلى محتوى iFrame عبر JavaScript غير ممكن.

يمكن الوصول إلى محتوى iframe عبر JavaScript _is_ ، طالما أنه على نفس النطاق ، كما هو الحال في هذه الحالة.

كيف يظل إجراء save_post متوافقًا مع الإصدارات السابقة؟ يوجد الكثير من المكونات الإضافية والسمات وخطافات الشفرة المخصصة في save_action والوصول إلى $ _POST super global. هذا ليس تصميمًا جيدًا ، لكنه دين فني يؤثر على ملايين المواقع.

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

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

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

أظن أن بعض المناقشة هنا تدور أيضًا جزئيًا حول العقارات المعروضة على الشاشة.

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

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

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

أتساءل عما إذا كان تضمين ملف تعريف قديم عبر إطار iframe يمكن أن يكون حلاً هنا

لا يُعد الوصول إلى إطارات iframe تجربة مثيرة للغاية لمستخدمي قارئ الشاشة. أي خيارات أخرى؟

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

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

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

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

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

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

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

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

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

سؤال كيف نحدد CPT بعدم استخدام Gutenberg (ما يعادل عدم وجود محرر) ، وإظهار فقط صناديق التعريف ذات العرض الكامل التي تعتمد عليها أعمالنا.
أنا أعتمد على الأيض. غالبًا ما تبدو CPTs الخاصة بي بهذا الشكل
'supports' => array( 'title' )
وتمتد من هناك. يرجى اعتبار أولئك منا الذين قاموا ببناء أدوات عمل للعملاء الذين يستخدمون CPTs مع مربعات التعريف كإدخال بيانات نموذج مقيد وموجه ، بدلاً من كتابة المقالات.
عملي هو في الغالب امتدادات مخصصة لـ CMB2 والتي تتعامل مع أنظمة العميل. EG قوائم العقارات التي تستدعي أنظمة الطرف الثالث.

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

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

هناك بعض مشكلات Guttenburg الفعلية ، والتي من المحتمل أن يتم رفع التذاكر المنفصلة لها (السماح لمربعات التعريف باستخدام العرض الكامل ، نموذج Guttenburg بدون دعم محرر) ، لكن Gutturnberg لا يمكنه نسخ الشاشات الحالية بالكامل ولا ينبغي عليه تجربة IMHO.

ومع ذلك ، فإنني أتساءل عما إذا كان ينبغي بذل المزيد من الجهد لجعل Guttenburg يختار الاشتراك / الانسحاب. بعض الأفكار:

• أعتقد أن معظم CPTs الحالية تستخدم بكثافة لصناديق التمثيل الغذائي على المحرر الرئيسي. لذلك ربما يجب على مؤلفي الإضافات الاشتراك في Gutturnberg 'supports' => array( 'gutenburg' ) أو ما شابه

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

• أو بدلاً من ذلك ، يمكن أن تعلن السمات عن الدعم عبر post_type_supports () ، ولكن هذا قد يضر بشدة الاستيعاب - أو يمكن للقوالب إلغاء الاشتراك الذي لن يساعد مستخدمي السمات القديمة غير المستقرة والتي لم تعد محدثة. (ربما يكون المكون الإضافي remove-guttenburn كافيًا لمستخدمي السمات القديمة رغم ذلك؟)

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

تعجبني الفكرة النظرية المتمثلة في طلب CPT صراحةً 'supports' => array( 'gutenberg' ) للحفاظ على الوظائف الحالية في حالة عدم تحديد علامة دعم "gutenberg". سيوفر لي الكثير من العمل في إصلاح المواقع القديمة للعملاء الغاضبين الذين قاموا بالتحديث إلى WP5.

ألاحظ أن ميزات "الدعم" الموجودة => (العنوان ، المحرر ، المؤلف ، ...) لها أسماء وصفية ذاتية للغاية ، يبرز Gutenberg هنا كاسم _ مشروع _. أتساءل عما إذا كان سيتم النظر في اسم ميزة أكثر وصفيًا لهذا الاستخدام ؛ ربما "محرر كتلة"؟ 'supports' => array( 'block-editor' )

بالطبع ستكون هناك حاجة إلى استراتيجية للقبض على أخطاء مثل 'supports' => array( 'title','editor',thumbnail', 'block-editor' ) . أفترض أن علامة "محرر الكتلة" ستتجاوز ببساطة وضع "المحرر" الأقدم.

البرنامج المساعد آخر مطور هنا مع المخاوف.

إذا كان يمكن الوصول إلى meta الشريط الجانبي فقط عبر JS ، فماذا يعني هذا بالنسبة لمربعات التعريف المسجلة في PHP ذات السياق side ؟ يؤدي نقلها إلى قسم "الإعدادات الموسعة" المقترح إلى إبطال فكرة أن هذه المربعات التعريفية سياقية.

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

بالنظر إلى JS-ification التدريجي لمنطقة الإدارة ، توفر هذه المربعات التعريفية "القديمة" أيضًا لمطوري المكونات الإضافية والقوالب نقطة تثبيت طبيعية لـ React / Vue / تطبيقات أخرى قائمة بذاتها لتوفير وظائف إضافية لصفحة التحرير.

المحرر يبدو رائعًا ، لكن من فضلك لا تنسَ بقية الصفحة.

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

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

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

شكرا على وقتكم يا رفاق ، إنه موضع تقدير.

ماذا عن جعل هذا المحرر يتصرف مثل محرر ملء الشاشة / خالٍ من التشتيت؟

+1

سأكرر اهتمامي الأساسي: غالبًا لا تتطلب CPTs "المحرر" لأن المنشور مبني من مربعات تعريف كبيرة ومجمعة ديناميكيًا في سير عمل موجه للمستخدم (على سبيل المثال بيانات منتج WooCommerce).

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

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

لقد تمت إضافة الكثير من الأفكار الجيدة هنا ، لذلك سأقوم فقط بإلقاء هذه الأفكار البسيطة:

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

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

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

آمل أن تساعد هذه الأفكار. إذا قال شخص آخر شيئًا بهذا المعنى ، فاعتبر ذلك اتفاقًا. 😄

أرغب في إضافة خطافين قيمين آخرين للمناقشة: edit_form_after_title و edit_form_after_editor اللذان يوفران حاليًا تحكمًا كاملاً في واجهة المستخدم بعد التحرير. من الواضح أن Gutenberg ليس مجرد بديل لـ "wp_editor" ، بل هو شكل مختلف تمامًا لواجهة المستخدم (وكما يبدو حاليًا ، قابلية التوسيع المعيارية المستقبلية).

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

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

من منظور المطورين / الأعمال / التخطيط ، سيكون من المفيد فهم النية (المستقبلية) لـ "Gutenberg" ، أو هل يمكن لشخص ما أن يوجهني إلى بيان المهمة هذا أو شيء مشابه؟

المزيد من الآراء مني ...

ألاحظ أن ميزات "الدعم" => (العنوان ، المحرر ، المؤلف ، ...) لها أسماء وصفية ذاتية للغاية ، يبرز Gutenberg كاسم مشروع هنا. أتساءل عما إذا كان سيتم النظر في اسم ميزة أكثر وصفيًا لهذا الاستخدام ؛ ربما "محرر كتلة"؟ 'يدعم' => مجموعة ('محرر كتلة')

أوافق - يبدو هذا وكأنه تفاصيل يمكن فرزها بمجرد الاتفاق على النهج رغم ذلك 😄

بالطبع يجب أن تكون هناك إستراتيجية للقبض على الأخطاء مثل 'support' => array ('title'، 'editor'، thumbnail '،' block-editor '). أفترض أن علامة "محرر الكتلة" ستتجاوز ببساطة وضع "المحرر" الأقدم.

أرى أن Gutenberg يمتد دعم نوع المنشور الحالي - لذلك إذا لم يكن هناك دعم editor فإن Gutenburg سيعرض خيارات العنوان / الشريط الجانبي / الموسعة. إذن ربما من الأفضل التعامل مع دعم جوتنبرج باعتباره وسيطة تسجيل CPT منفصلة ، بدلاً من أن يكون جزءًا من مصفوفة الدعم؟

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

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

من المحتمل أيضًا أن تكون هناك طريقة لتعيين واحد (أو أكثر؟) أو هذه على أنها مفتوحة عند تحميل الصفحة - خاصةً إذا كان نوع المنشور لا يدعم المحرر الرئيسي.

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

إذا كانت الشاشة الجديدة المستندة إلى رد الفعل قابلة للتوصيل مثل شاشات التحرير القديمة ، فلا يوجد سبب يمنع إضافة مهام سير العمل المخصصة هذه إلى أعلى الصفحة / الشريط الجانبي / أسفل المحرر أو في أي مكان آخر على الصفحة. (إخلاء المسؤولية: ليس لدي فهم عميق لـ React ، لذلك يبقى أن نرى كم ستكون الخطافات الأكثر تعقيدًا خارج PHP). أيضا # 1352

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

عندما تحدد نوع منشور مخصص ، فمن المحتمل أن يتضمن ذلك الكتل المطلوبة وأي الكتل مسموح بها فقط. بالنسبة لنوع المنشور المخصص الذي لا يحتوي على دعم editor فسيظل "المحرر" معروضًا في Gutenberg ، ولكن يمكنه بشكل أساسي تعطيل _inserter_. سيتم قفل الكتل التي تظهر في المحرر في مكانها وفقًا لما يتطلبه نوع المنشور. إذا لم يتم ملء الكتل ، فستظهر على أنها _أصحاب أماكن_. لاحظ أن هذه الكتل يمكنها بعد ذلك تخزين خصائصها في postmeta تمامًا مثل صناديق التعريف الموجودة حاليًا ، لكنها ستفعل ذلك بطريقة طبيعية بدلاً من مخصصة عبر الإجراء save_post و $_POST global.

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

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

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

شكرًا على westonruter للتوضيح ولكن هذا يثير سؤالين جديدين بالنسبة لي.

تبدو الكتل التي تخزن بياناتها على أنها post_meta نوعًا مختلفًا تمامًا من الكتلة عما رأيته حتى الآن في العرض التوضيحي. هل سيتم تخزين هذه البيانات بشكل متكرر في تدفق محتوى المنشور؟

هل هناك أي شيء يمنع المؤلف من إضافة أكثر من عدد مقبول من الكتل إلى منشور؟ (إضافة عدة حقول post_meta عندما يكون واحدًا فقط منطقيًا)

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

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

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

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

... يجب أن نبتعد عن التفكير في إضافة مربعات الأيض والتفكير بدلاً من ذلك في إضافة الكتل.

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

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

westonruter هل يمكنك أن توضح أن ما تقوله هو أنه إذا كان نوع

إذا كان الأمر كذلك ، فلدي بعض أسئلة المتابعة:

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

2) كيف سيتم حفظ البيانات من تلك الكتلة؟ كما أفهمها ، يتم الآن تخزين البيانات من الكتل كتعليقات HTML في post_content. كيف نحصل على البيانات من هذه الكتل لنشر التعريف؟ على سبيل المثال ، بالنسبة للمكوِّن الإضافي للحدث الافتراضي ، كيف يمكنني الحصول على تاريخ البدء والانتهاء في التعريف المنشور حتى أتمكن من الاستعلام بواسطتهما؟

3) ما هو الأساس المنطقي لهذا كل شيء يسير في اتجاه محرر المحتوى الرئيسي وتطبيقه على أنواع المنشورات المخصصة؟ هل هناك أي اختبار للمستخدم يدعم اتجاه التصميم هذا ، خاصةً فيما يتعلق بأنواع المنشورات المخصصة التي لا تمثل منشور / مقالة مدونة؟

kevinwhoffman ما زلت لا أرى تعارضًا أساسيًا للكتل. لا يزال من الممكن اعتبار الإعدادات المجردة محتوى ، ولكن من نوع مختلف: إنها جميع البيانات. لا تحتاج كل كتلة إلى تمثيل مرئي في "المحتوى". أعتقد أنه يمكن أن يكون هناك الكثير من "وحدات التشغيل" أيضًا ، حيث يتم تخزين البيانات في postmeta بدلاً من post_content . يمكن للكتل التي يتم تحريرها أن تصمم بحيث تحتوي على عناوين / تسميات مشابهة لكيفية تقديم مربعات التعريف اليوم.

@ Shelob9 نعم ، إذا كان نوع product-details تحتوي على حقول للسعر ، والصيغ ، وما إلى ذلك.

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

نعم بالضبط. يمكن أن تتضمن أنواع المنشورات المخصصة ، وتنسيقات المنشورات ، وقوالب الصفحات مفهوم الكتل المطلوبة "المقفلة" ، والتي لا يمكن إزالتها أو إعادة ترتيبها. أحد الأمثلة على ذلك هو حظر مقتطف المنشور: https://github.com/WordPress/gutenberg/issues/1288#issuecomment -310544967

1. كيف سيتم حفظ البيانات من تلك الكتلة؟ كما أفهمها ، يتم الآن تخزين البيانات من الكتل كتعليقات HTML في post_content. كيف نحصل على البيانات من هذه الكتل لنشر التعريف؟ على سبيل المثال ، بالنسبة للمكوِّن الإضافي للحدث الافتراضي ، كيف يمكنني الحصول على تاريخ البدء والانتهاء في التعريف المنشور حتى أتمكن من الاستعلام بواسطتهما؟

تخزن معظم الكتل اليوم بياناتها بتنسيق HTML داخل post_content لكن لا يتعين عليهم ذلك. على سبيل المثال ، في https://github.com/WordPress/gutenberg/issues/1288 ، يمكنك مشاهدة مناقشة حول كتلة مقتطفات تخزن محتواها في post_excerpt وكتلة صورة مميزة تخزن محتواها في postmeta. لذلك يجب أن تكون قادرًا بالتأكيد على الحصول على كتلة event-details لها تاريخ بدء وانتهاء يتم تخزينها في postmeta.

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

كما ورد أعلاه ، يمكن الحصول على البيانات وحفظها في post_content أو postmeta أو الشروط أو أي مكان آخر. فكرة أن تكون "الكتلة أولاً" هي أن يكون لديك مبنى مشترك _Block_ يستخدمه كل شيء ، وبذلك يمكن إعادة استخدام مكونات الكتلة إلى أقصى حد عبر WordPress. هذا ما فهمته.

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

آمل أن نرى وثائق حول كيفية كتابة "بيانات" قريبًا.

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

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

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

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

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

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

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

brentjett شكرا على

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

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

لا أرى فائدة طلب مربع إعدادات مثل Yoast ليكون كتلة في المقام الأول.

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

الشيء الآخر هو الإجابة على السؤال: إذا أردنا إعادة تصميم هذا من الألف إلى الياء ، كيف سيبدو اليوم؟

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

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

إذن ، لدينا حالتان وظيفيتان _ Legacy_:
MetaBoxes التي تعاملت مع البيانات الوصفية (مثل Yoast) ، ولدينا MetaBoxes التي تم استخدامها لتوفير واجهة منظمة لإدخال المحتوى (مثل WooCommerce).

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

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

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

• تبدو المواقع القديمة التي تعتمد على CMS meta-box وقاعدة المستخدمين الخاصة بها غير ضرورية للفريق الأساسي
• تم إلغاء ترتيب أولويات اقتراح السحب "المتقدم" رقم 952 ، مما يشير إلى عدم الاهتمام بالمنطقة بأكملها.
• لا توجد طريقة مقترحة لحل مشكلة "الديون إلى الماضي" / CMS

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

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

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

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

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

قسم مخاوف steveangstrom هو تلخيص كبير للمخاوف التي لم يتم الرد عليها بعد.

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

أنا أتفهم هذه المخاوف لأن لدي أيضًا العديد من العملاء الذين من المحتمل أن تتوقف مواقعهم عن التحديث. بعض الأفكار مني:

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

ميزة أخرى لـ ACF لا تتناسب مع تدفق تحرير المنشور هي صفحات الخيارات. أنا حقًا لا أرى كيف سيعمل هذا على صفحة الخيارات.

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

ووردبريس لا يتبع semver.

westonruter أعتقد أن هذا منطقي:

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

لكن كيف ننتقل من هناك (مربعات الأيض) إلى هنا (كتل)؟ سواء من حيث backcompat للشفرة (المكونات الإضافية التي لم يتم تحديثها بعد لـ Gutenberg) و backcompat للبيانات (كيف نعرض بيانات metox الحالية في كتلة محتوى جديدة ، بمجرد تحديث مكون إضافي لها ؛ هل هذا مكون إضافي- مشكلة النطاق؟).

لكن كيف ننتقل من هناك (مربعات الأيض) إلى هنا (كتل)؟ سواء من حيث backcompat للشفرة (المكونات الإضافية التي لم يتم تحديثها بعد لـ Gutenberg) و backcompat للبيانات (كيف نعرض بيانات metox الحالية في كتلة محتوى جديدة ، بمجرد تحديث مكون إضافي لها ؛ هل هذا مكون إضافي- مشكلة النطاق؟).

هذه أسئلة جيدة. سنستكشف الإجابات أثناء تنفيذنا لهذه الميزات.

إذا اضطررت إلى تخمين المكان الذي سننتهي إليه هنا: سيتم نقل مربعات التعريف الحالية إلى منطقة "قديمة" وسنوفر واجهات برمجة التطبيقات (API) والوثائق والأمثلة لتسجيل "النمط الجديد" لكتل ​​التمثيل الغذائي.

@ nylen ماذا عن _ rendering_ في مربعات التعريف الحالية؟

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

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

لذا يبقى السؤال ، ماذا يحدث للواجهة التي لا تحتوي على محرر وتتألف بالكامل من مربعات التعريف؟

لذا يبقى السؤال ، ماذا يحدث للواجهة التي لا تحتوي على محرر وتتألف بالكامل من مربعات التعريف؟

الفكرة هنا ، وصححني إذا كنت مخطئًا

ماذا عن جعل هذا المحرر يتصرف مثل محرر ملء الشاشة / خالٍ من التشتيت؟

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

أيضًا ، سيكون من الأفضل تسجيل الدعم لمحرر Gutenberg باستخدام المعلمة supports عند register_post_type .

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

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

كلما تمكنا من تحديث ACF و Pods و CMB2 لاستخدام نموذج البيانات الذي قدمه Gutenberg ، سيكون هذا الانتقال أسهل على ما أعتقد.

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

I can guarantee there will be a pretty significant outcry if CMB2 is somehow broken when WordPress 5.0 is released

وحتى إذا تم تحديثه ، فستتعطل عمليات التثبيت القديمة.

يرجى أيضًا ملاحظة أن مجموعات الحقول في ACF لا تحتاج إلى أن تكون في مربعات تعريف ، ولكن هناك أيضًا نمط "سلس (بدون ملف تعريف)" مع خيارات "جانب" و "عادي - بعد المحتوى" و "مرتفع - بين العنوان والمحرر (!!!) '. العنصر الأخير مهم لإنشاء تدفق ذي معنى للتحرير.

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

@ wsydney76 يرجى أيضًا ملاحظة أن مجموعات الحقول في ACF لا تحتاج إلى أن تكون في مربعات تعريف ، ولكن هناك أيضًا نمط "سلس (بدون ملف تعريف)" مع خيارات "جانبي" و "عادي - بعد المحتوى" و "مرتفع - بين العنوان ومحرر (!!!) '. العنصر الأخير مهم لإنشاء تدفق ذي معنى للتحرير.

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

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

فيما يتعلق بالتوافق مع الإصدارات السابقة ، اقترحت إصدار دعم طويل الأجل من WordPress في فبراير ، قبل وقت طويل من الإعلان عن Gutenberg يصل إلى 5.0.

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

يمكن العثور على المنشور هنا:
https://khromov.se/wordpress-needs-another-long-term-support-version/

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

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

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

كيف يتلاءم جوتنبرج مع هذه الرؤية؟

لا أرى حلاً بخلاف إبقاء هذا المحرر اختياريًا ، أي أنه يجب أن يحل محل TinyMCE ولكن يجب أن يظل المحرر اختياريًا تمامًا مثل TinyMCE اختياري في الوقت الحالي.

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

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

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

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

نحن نخطط لاستخدام Pods 2.7 لبناء تطبيق مدعوم من React باستخدام WordPress REST API و
هل سيكون Gutenberg متوافقًا مع Pods؟

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

لقد صنعت مولدات الأكواد الخاصة بي مستوحاة من GenerateWP. لاستخدامي الشخصي والخاص على المضيف المحلي ، وليس العام.
على أي حال ، أتساءل كيف سيبدو في Gutenberg عند الانتهاء من التبديل. حقول ACF ، الكثير من كود PHP المخصص للمعاينة.

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

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

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

هذه نقطة بداية لقائمة المكونات الإضافية التي يجب النظر إليها:

Plugin                                      Active installs
======                                      ===============
advanced-custom-fields                           1,000,000+
custom-post-type-ui                                400,000+
meta-box                                           200,000+
types                                              200,000+
cmb2                                               100,000+
pods                                                50,000+
custom-field-suite                                  40,000+
wck-custom-fields-and-custom-post-types-creator     20,000+
piklist                                             10,000+
carbon-fields                                        2,000+

الإضافات التي لا تظهر أعلاه ، على الأرجح لأنها ليست في دليل البرنامج المساعد WP.org:

• المدير الميداني

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

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

تضيف الحقول المخصصة المتقدمة مربعات التعريف الخاصة بها عن طريق تسجيل خطاف مقابل admin_enqueue_scripts . يتحقق هذا الخطاف من أن تحميل الصفحة الحالية إما post.php أو post-new.php ، وإذا كان الأمر كذلك ، يضيف إجراء admin_head الذي يستدعي add_meta_box . تقوم WP core بإجراء مكالماتها do_meta_boxes بعد هذا الإجراء بفترة وجيزة ، في edit-form-advanced.php .

أخيرًا ، إذا كنت مطورًا على دراية بالطريقة التي يعرض بها WordPress حاليًا مربعات التعريف ويحفظها ، فإن إدخالك هنا و / أو على # 2251 موضع تقدير .

اهلا ياجماعة،
إليوت هنا - ACF dev.

يستخدم ACF الإجراء admin_enqueue_scripts لتنفيذ "منطق مطابقة مجموعة الحقول" ثم الإجراء admin_head لإضافة مربعات التعريف (عبر add_meta_box() ). لا يستخدم الإجراء add_meta_boxes .

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

يرجى التأكد من وضع علامة في woocommerce أيضًا. هم على الأرجح أكبر مكون إضافي لبرنامج التمثيل الغذائي.

شكر
ه

اهلا ياجماعة-

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

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

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

كما قلت ، فقط أحاول أن أضيف إلى سياق المحادثة.

شكر،

كيفن - المطور الرئيسي لـ Piklist

تمت الإشارة إلى هذا السؤال في العديد من التعليقات أعلاه ولكن لم تتم الإجابة عليه على حد علمي:

هل من الممكن استبدال محرر منشورات TinyMCE الحالي بـ Gutenberg مع ترك باقي الواجهة ، بما في ذلك مربعات التعريف والخطافات الحالية ، دون تغيير؟

سيسمح هذا النطاق الضيق بتضمين Gutenberg أو استبعاده من أنواع المنشورات المخصصة من خلال تحديد دعم editor عند تسجيل نوع المنشور.

• إذا تم تسجيل دعم editor ، فسيكون Gutenberg موجودًا على شاشة التحرير مع استمرار عمل مربعات التعريف الحالية كما تفعل اليوم حول المحرر الحالي.
• إذا لم يتم تسجيل دعم editor ، فلن يتم تحميل Gutenberg وتكون اللوحة الفارغة متاحة لمربعات التعريف كما هي اليوم.

يبدو أن هذا الأسلوب يتجنب التحدي الهائل المتمثل في التوافق العكسي مع تطبيقات meta box الحالية مع تحرير الموارد لجعل أفضل محرر ممكن.

هل يمكنني طرح سؤال واضح هنا؟ لماذا نناقش "صعوبات" الأيض؟

elliotcondon - إذا كان من الصعب حل مشكلة مطور ، فإن الطريقة الوحيدة للوصول إلى حل هي

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

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

لماذا نتحدث فقط عن إضافة الحقول إلى مربعات التعريف؟

أود الوصول إلى مكان لا يجب أن يهتم فيه كود جوتنبرج كثيرًا بما يفعله نظام التمثيل الغذائي بالفعل.

لتحقيق هذا الهدف ، kevinpmiller ، إليك الأشياء التالية التي سيكون من المفيد معرفتها لـ Piklist:

• ما هي الإجراءات المسؤولة عن استدعاء add_meta_box لتسجيل مربعات التعريف
• أي شروط تتحكم في تسجيلهم أم لا (على سبيل المثال ، الشاشة الحالية هي post.php أو post-new.php )

في هذه المشكلة ، دعنا نحافظ على تركيز المحادثة على جعل مربعات تعريف PHP الحالية تعمل جنبًا إلى جنب مع واجهة Gutenberg.

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

نعم ، نحن بحاجة إلى عمل مجموعة من واجهات برمجة التطبيقات لإنشاء مربعات تعريف "نمط جديد". إليك ما لدينا اليوم للكتل - أتوقع أنه سيكون متشابهًا إلى حد كبير ، مع تسجيل مربعات التعريف على أنها "كتل" يمكن أن توفر في مكان آخر غير post_content : http://gutenberg-devdoc.surge.sh/

يجب أن تحدث المناقشة حول مربعات التعريف ذات النمط الجديد في # 1684 أو قضية منفصلة لاقتراح واجهة برمجة تطبيقات فنية.

إذا لم يتم تسجيل دعم editor ، فلن يتم تحميل Gutenberg وتكون اللوحة الفارغة متاحة لمربعات التعريف كما هي اليوم.

kevinwhoffman - جوتنبرج كما هو مكتوب اليوم من المفترض أن يكون محرر post_content . لذا فمن المنطقي أنه إذا لم يتم تمكين دعم editor ، فعندئذ على الأقل في الوقت الحالي ، نقوم بتعطيله. هذه أيضًا مهمة سهلة جدًا من منظور الكود. هل يمكنك إنشاء عدد جديد لهذا ، وسأضع علامة عليه بعلامة Good First Task ؟

من المفترض أن يكون Gutenberg كما هو مكتوب اليوم محررًا post_content .

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

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

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

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

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

لماذا نناقش "صعوبات" الأيض

يسعدني قراءة ما يلي:

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

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

تضمين التغريدة
يدرج ACF عددًا قليلاً من ملفات JS و CSS لتصميم عنصر HTML والتعويض عن ACF والتفاعل معه.
يستخدم ACF إجراءات "admin_enqueue_scripts" لإضافة هذه الأصول
العديد من الإضافات والقوالب الأخرى تُدرج الأنماط / البرامج النصية - لماذا قد تكون هذه مشكلة؟
لا يستخدم ACF JS لحفظ البيانات الوصفية. يستخدم الإجراء save_post لحفظ أي بيانات $_POST - أشياء عادية جدًا.

علاوة على ذلك ، فإن الحاجة إلى واجهة برمجة تطبيقات لترجمة مربعات التعريف PHP إلى مربعات وصفية لـ React هي مشكلة مصنّعة.

هذا ليس بالضبط ما نفعله. إنه أشبه بما يلي: نظرًا لأننا لم نعد نستخدم عملية التحميل التقليدية post.php ، فنحن بحاجة إلى اختيار الأشياء التي نحتاجها منها.

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

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

kevinwhoffmanelliotcondonnylen أو الأفضل من ذلك، ماذا عن:

• إذا تم تسجيل دعم block-editor ، فاستخدم Gutenberg.
• إذا تم تسجيل دعم editor ، فاستخدم TinyMCE.
• إذا لم يتم تسجيل أي دعم ، فلن يتم تحميل Gutenberg أو TinyMCE.

أنا لا أؤيد كسر تجربة مشرف WP استنادًا إلى وجود أو عدم وجود Gutenberg.

إذا كان Gutenberg = New React Meta Boxes and No Gutenberg = Old PHP Meta Boxes ، فإن المسؤول المكسور هو الاتجاه الذي نتجه إليه.

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

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

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

أنا لا أؤيد كسر تجربة مشرف WP استنادًا إلى وجود أو عدم وجود Gutenberg.

هل كان ذلك ردًا على اقتراحي بخصوص block-editor أو أي شيء آخر؟

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

mikeschinkel إن القدرة على تمكين أو تعطيل Gutenberg ضرورية ، لكن فكرة تحديد Gutenberg لسلوك Meta box هي ما أعارضه. هذه قضايا منفصلة.

kevinwhoffman أنا أتفق معك ، راجع للشغل.

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

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

-1 على الاضطرار إلى إعادة كتابة كل شيء في React ، على الأقل ادعم كلاهما لفترة طويلة حتى يتاح للجميع الوقت للارتياح مع طريقة React وتدعم المزيد / تعمل على حل مكامن الخلل في تطبيقات meta box. لا أعتقد أن هناك وقتًا يجب فيه التخلص التدريجي من المربعات الوصفية لـ PHP ، والاحتفاظ بها من أجل backcompat والسماح للمكونات الإضافية بالانتقال حيث تتحسن وثائق React meta box ومهارات المطور في هذا المجال.

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

هل ينوي WordPress إهمال Metabox API رسميًا؟

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

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

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

شاشة تحرير المنشور هي الشاشة الأكثر تخصيصًا في كل مشروع والتي تتجاوز مدونة مجردة.

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

لذلك بالنسبة لهذه التخصيصات ، يجب أن يكون هناك طريق للمضي قدمًا.

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

وبالتالي ، لا يزال يتم إنشاء العديد من مربعات التعريف باستخدام رمز مخصص. الكود المخصص يعني مزيجًا من PHP و JavaScript ، غالبًا مع تفاعلات Ajax.

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

أي تراجع من خيارات التخصيص على شاشة Post Edit المتوفرة الآن سيكون غير مقبول.

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

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

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

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

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

@ fklein-lu أعارض بشدة أن يكون مدير الحقول هو "الأداة المفضلة". لا أراه حتى في قائمة أفضل 10 حقول إضافية.
https://github.com/WordPress/gutenberg/issues/952#issuecomment -320523428

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

كيف يمكن للمرء إضافة Metaboxes إلى شاشة الواجهة الخلفية للوحة المعلومات؟
لا علاقة له بجوتنبرج.

khromov اقرأ ما كتبته بالفعل ، بدلاً من هذا المنصب يتم الرجوع، وكنت أعرف لماذا Fieldmanager لا يجعل من قائمة العشرة الأوائل.

@ fklein-lu لست متأكدًا من سبب اعتقادك أنني أخطأت في اقتباس أقوالك ، إليك السياق الكامل: "بالنسبة إلى مربعات التعريف ، يعد Fieldmanager هو الأداة المفضلة ، نظرًا لأنه تمت الموافقة عليه من قبل VIP." لا أعرف أي شخص يستخدم Fieldmanager ، لذلك أجد صعوبة في فهم هذا الاقتباس.

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

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

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

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

TL ؛ DR: لا تتوقع أن يقوم عملاء المؤسسات بتحديث التعليمات البرمجية الخاصة بهم خلال الـ 12 شهرًا القادمة لأشياء أخرى غير الصيانة. أضف سياسة إهمال / تحذير مع جدول زمني مناسب. توقع انخفاضًا كبيرًا في الثقة في WordPress ، عندما تفرض تغييرًا (حتى للأفضل) من حيث الواجهة الخلفية وإمكانية استخدام الكود.

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

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

من الصعب مناقشة كل هذا بينما لا يزال الثقب الأسود بالنسبة لي. وأنا لست الوحيد.

فقط لكي أذكر كم أنا موضوعي في هذا الأمر ، لا تحاول:

• ما زلت أعتقد أن TinyMce وشاشة البريد القديمة (مع Metaboxes) هي أجمل شيء رأيته في عالم CMS. الوظائف والفلاتر والتوسعات والتصميم الجميل. نعم الجمال الخالص والسرور.
• على الرغم من ذلك قبلت جوتنبرج منذ اليوم الأول. نعم ، تخلص من كل هذا "القديم" ، وقم بالتبديل ولا تنظر إلى الوراء أبدًا.

كانوا يعرفون شيئًا لا أعرفه. هم يمتلكون رمز. لكني لست متأكدا بعد الآن.

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

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

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

أريد أيضًا إجراء +1 لـ Rarst وkevinwhoffman. لا يزال من الممكن أن يؤدي الحفاظ على الدعم الكامل لصناديق التمثيل الغذائي الحالية إلى تمكين المستقبل حيث نستبدل الميثانول "القديمة" بمكافئات TBD Gutenberg. لكن عدم اليقين الذي يحيط الآن بالتوافق العكسي يجب تخفيفه في أسرع وقت ممكن.

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

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

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

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

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

@ fklein-lu انظر أعلاه ، نحن نستمع ويمكنك دائمًا التواصل إذا كنت تريد التعاون في البرمجة!

بالنسبة إلى VIP وسوق المؤسسات ، أتوقع أنه سيكون هناك أكثر من بضع محادثات حول هذا الموضوع في WordCamp for Publishers الأسبوع المقبل في دنفر . ومع ذلك ، فقد تواصلنا مع Gutenberg devs & m لكن AFAIK لن يتمكن أحد من الحضور.

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

ولدي موقع ويب واحد يستخدم Jetpack ولديه زائران فريدان فقط في اليوم.
توقف عن الإساءة بسهولة. إنه WordPress ، وليس مناقشة حول إصدار Joomla الجديد. :)

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

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

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

هل ينوي WordPress إهمال Metabox API رسميًا؟

لا.

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

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

ومع ذلك ، هناك عدة طرق يمكن من خلالها معالجة المربعات الوصفية وقابلية التمدد:

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

أو أي مزيج من هؤلاء.

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

لا.

شكرا لك ، أعتقد أن الكثير من الناس قد زفروا للتو.

السؤال الذي لم تتم الإجابة عليه بالكامل حتى الآن هو كيف تعمل المربعات الوصفية في سياق محرر جوتنبرج.

لماذا _are_ meta box في سياق محرر Gutenberg؟

يبدو أن الإجابة هي أن Gutenberg يهدف إلى استبدال محرر المنشورات بالكامل _screen_ بالتنفيذ الذي يحركه JS. لم أتابع التطوير لأكون على دراية بأسباب ذلك.

لكنني ما زلت أعتقد أنها كانت نقطة صحيحة للغاية أثيرت - إذا كان نطاق Gutenberg سيكون مكون محرر ، فإن استبدال نطاق _screen_ يبدو طموحًا للغاية. _If_ نطاق Gutenberg هو (على الأقل جزئيًا) استبدال WordPress _admin_ ككل ، فهو نطاق أوسع وأكثر تطلبًا بشكل لا يصدق. لا يعني ذلك أن استبدال المحرر "العادل" ليس بالأمر السهل.

ومع ذلك ، هناك عدة طرق يمكن من خلالها التعامل مع المربعات الوصفية وقابلية التمدد

تم تحديد نطاق Gutenberg ليحل محل مكون _editor_ الرئيسي وما زالت واجهة مستخدم المشرف الحالية تعمل فقط؟ هل _ هذا _ قيد النظر ، إذا لم يكن الأمر كذلك ، فلماذا؟

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

لأنني مررت بمشكلة بناء بنية شديدة الانفصال مع فئات وواجهات تجريدية مشتركة ، كل ما علي فعله هو إضافة "موقع" جديد. إليك مكونات البنية ذات الصلة بنظري:

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

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

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

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

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

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

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

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

شكر.

تم تحديد نطاق Gutenberg ليحل محل مكون المحرر الرئيسي وما زالت واجهة المستخدم الحالية للمشرف تعمل فقط؟ هل يتم النظر في هذا ، إذا لم يكن الأمر كذلك فلماذا؟

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

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

لم ننتهي بعد ، والأمر ليس سهلاً ، لكننا نعمل عليه كل يوم.

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

محرر جوتنبرج الجديد ومستقبل ButterBean

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

الريبو: https://github.com/justintadlock/butterbean/tree/dev

لأغراض الاختبار ، تم تضمين إطار العمل في هذا المكون الإضافي: https://github.com/justintadlock/custom-content-portfolio

ButterBean عبارة عن إطار عمل يتم إنشاؤه باستخدام Backbone.js و Underscore.js. تم تصميمه بشكل كبير من أداة التخصيص في WP الأساسية.

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

الخطافات المستخدمة

فيما يلي خطاطيف WP الأساسية المستخدمة (قياسية جدًا لمعظم أطر عمل الميتا بوكس ​​، كما أتخيل):

load-post.php
load-post-new.php 
add_meta_boxes
save_post 
admin_enqueue_scripts
admin_footer 
admin_print_footer_scripts

تم إنشاء # 2265 لتوثيق الخطافات ذات الصلة لـ CMB2.

تمت إضافة ملصق تصميم لتشجيع الأشخاص على إضافة نماذج إضافية.

بشكل عام ، أشعر أن البيانات التي ليست جزءًا من المحتوى المعروض لا ينبغي أن تكون جزءًا من منطقة التحرير الرئيسية. ليس كل شيء كتلة.

1) غالبية مربعات التعريف المخصصة الخاصة بي مصنوعة من Fieldmanager . من وجهة نظري ، يجب أن "تعمل فقط" دون الحاجة إلى عمل إضافي من جانبي إلى جانب التحديث. cc / mboynes و bcampeau حيث أنهما قد

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

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

4) لقد قمت بإزالة مربع تعريف الفئة في الماضي واستبدلت به: 1) اختيار راديو 2) إصدار بدون القدرة على إضافة فئات جديدة (كان هذا غبيًا).

5) لقد استخدمت post_submitbox_misc_actions لإضافة خيارات إلى مربع تعريف النشر الذي لا يلزم أن يكون في مربع التعريف الخاص بهم.

بقدر ما أعنيه بقدر كبير من الوقت ، أود أن أقول حوالي عامين من النقطة التي تم فيها تجميد Gutenberg API.

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

• 'edit_form_top'
• 'edit_form_after_title'
• 'edit_form_before_permalink'
• 'edit_form_after_editor'
• 'edit_form_advanced'

أريد فقط أن أعيد ما قاله خطاف edit_form_[POSITION] . يستخدم Piklist بشدة في المربعات الوصفية وسير العمل وأشياء أخرى.

شكرا مرة أخرى على وقتك يا رفاق.

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

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

أولاً ، من الرائع رؤية تقدم حقيقي في هذا الشأن.

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

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

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

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

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

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

يبدو أن نموذج

rilwis أعتقد أنه يجب عليك

لإلهام التصميم ، يمكنك التحقق من سمات مسؤول الخلفية المجانية والتجارية (لقطات الشاشة). أو أي منصة أخرى.

لوحة القيادة ، لكن تخيل جوتنبرج:

ربما ستحل Fields API المقترحة بعض المشكلات المتعلقة بدعم مربعات التعريف في المحرر الجديد

السيناريو الذي يجب أن نفكر فيه هو ما يحدث عندما يتم تحديث WordPress باستخدام Gutenberg والمكونات الإضافية التي نفذت المربعات الوصفية ليست كذلك .

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

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

فمن الواضح أن:

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

وبالتالي:

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

dmccan لا ، هذه العبارات ليست "واضحة" مثل كل الحلول المقترحة حتى الآن إما:

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

لم أشدد على السيناريو الأسوأ ليكون ميلودراميًا ؛ لقد فعلت ذلك لتحديد القيود التي يجب أن نتعامل معها مع المشكلة.

لذلك يبدو أنه من المحتمل أن يظل Gutenberg مكونًا إضافيًا للميزات لفترة طويلة ، وهو مكون يمكن للأشخاص اختياره إذا رغبوا في ذلك أو الانسحاب منه إذا لم يكن كذلك ، وربما يتم تضمينه كمكوِّن إضافي مع النواة.

سوف يستغرق حل جميع المشكلات التي يحتاج إلى حلها من أجل الحصول على تجربة محرر واحدة الكثير من وقت التقويم. ما عليك سوى إلقاء نظرة على ASP.NET الأصلي من Microsoft ومدى سوء حلها لمشكلة الويب العامة. في نهاية المطاف ظهرت AJAX والباقي هو التاريخ.

قد يؤدي فرض التغيير بسرعة كبيرة إلى أن يصبح WordPress منصة حقيقية قديمة فقط.

ملاحظة: يبدو أن شرط "المحرر الفردي" غير واقعي. إذا كان لدى المستخدمين خيار استخدام القديم أو الجديد ، فيمكن السماح للجديد بالتطور بمرور الوقت حتى لا يكون هناك أي فائدة لاستخدام القديم. ولكن ما دامت هناك عمليات تثبيت تستخدم الخطافات الحالية _ (على ما أعتقد) _ فمن غير المسؤول استخدام حل محرر واحد. #jmtcw

kevinwhoffman - أعتقد أننا نتفق ، لكن ربما لم أكن مطوّلًا بما يكفي.

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

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

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

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

ربما يجب عليهم (المبرمجون الأساسيون) التحدث إلى مات. لقد بدأ كل هذا وليس لديهم الآن إجابات.

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

كملاحظة جانبية ، على الرغم من أنني لم أستخدم مطلقًا React أو Vue _ (أنا مطور PHP) _ فإن المناقشة حول React تتطلب نظام بناء وأن العديد من الأشخاص وجدوا أن Vue أسهل في الاستخدام من React جعلني أشعر بقلق شديد بشأن ذلك ما إذا كان Gutenburg سيكون لديه وسيلة سهلة للتعلم واستخدام نموذج التمدد أم لا ، وما إذا كان ذلك سيعني أنه يمكننا الاستمرار في استخدام WordPress لمشاريع العميل أم لا.

فقط ملاحظاتي للإشارة إلى قلقي ، لا داعي للرد مباشرة على هذا.

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

يتعلق الأمر بمحرر المظهر المرئي الكامل للواجهة الأمامية.

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

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

بالإضافة إلى ذلك ، قمت بإنشاء # 2308 لسرد الخطافات ذات الصلة من المكون الإضافي Meta Box.

ahmadawais شكرا على الذكر.

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

nylen أحافظ على الحقول المخصصة لمطور البرنامج المساعد

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

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

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

tldr. يجب أن يحل Gutenberg محل محرر TinyMCE فقط لأنواع المنشورات التي تحتاج إلى تكوين محتوى.

فقط أضف سنتي هنا.

لماذا لا تتركها كما هي الآن؟ ما أعنيه هو هذا.

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

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

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

سيؤدي هذا أيضًا إلى فصل الاثنين مما يسمح بطريقتين مختلفتين للحفظ. يمكن لـ Gutenberg استخدام JS ويمكن للكلاسيكي الاستمرار في استخدام PHP.

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

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

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

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

هناك طريقة أخرى للتعامل مع هذا الأمر وهي استخدام نفس سير العمل مثل Beaver Builder . أي احتفظ بصفحة تحرير المنشور العادية (مع أقسام Meta Box المعتادة وما إلى ذلك) ثم يمكن تشغيل Gutenberg عبر زر. يمكن أن ينقلك هذا بعد ذلك إلى شاشة جديدة. يشبه إلى حد كبير التعليقات حول استهداف وضع الكتابة الحرة إلهاء.

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

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

توضح قراءة هذا الموضوع بالكامل شيئين بالنسبة لي:

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

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

إذا كانت هناك مناقشة مركزة على API تحدث بالفعل ، فهل يمكن لشخص ما أن يوجهني وأي شخص آخر لا يعرف أين يحدث هذا في الاتجاه الصحيح؟ شكر!

هل هناك سبب لعدم تقسيم المحرر إلى شاشتين يتم التنقل بينهما عبر علامات التبويب؟

وجهة نظري هي أن جوتنبرج ،

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

المشاكل ، كما هو موضح أعلاه وكما يشعر بها معظم المطورين والمستخدمين النهائيين ، هي أن Gutenberg ،

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

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

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

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

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

هذه إقتراحاتي:

• قدم Tabify Edit Screens في محرر الصفحة.
• انقل مربعات التعريف إلى علامة تبويب الصفحة الخاصة بها داخل شاشة المحرر.
• استخدم صفحة لا تعتمد على React لمربعات التعريف (الصفحة مخفية خلف علامة تبويب محرر)
• استخدم لوحة رسم افتراضية TinyMCE (أو محرر غني بالميزات) تعمل بشكل جيد مع الشكل الطويل ولا تصر على استخدام المؤلفين للكتل.
• قدم Guttenberg Blocks كإضافة إلى TinyMCE أو TinyMCE الشبيه.
• قم بتقديم Shortcake إلى المحرر المستند إلى TinyMCE بحيث يتمكن المؤلفون من رؤية محتوى الكتل بشكل مرئي بحيث يمكن للمؤلفين تحرير المحتوى مباشرة في تدفق الصفحة دون الحاجة إلى النقر فوق زر تحرير لكل كتلة.
• اجعل من السهل على المطورين إضافة كتل جديدة إلى Guttenberg عن طريق ربط add_shortcode () في إنشاء الكتلة مثل add_shortcode ('tag' ، 'function' ، 'guttenberg true / false'). قم بتكييف add_shortcode بحيث يجعل الرمز القصير متوافقًا تلقائيًا مع Guttenberg ؛ سيسمح هذا للمطورين بتحويل بعض / العديد من مربعات التعريف الخاصة بهم بسهولة إلى أكواد قصيرة تعمل داخل Guttenberg.

ما أقوله حقًا هو أن Guttenberg يحتاج إلى تقسيمه إلى 3 مهام:

• تنظيف شاشة المحرر
• محرر واجهة مستخدم محسّن
• تحسين إطار عمل ملحق المحرر.

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

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

لقد استطردت من موضوع الموضوع الأصلي ولكن هذا يجب أن يقال: Guttenberg سيقتل WordPress.

إذا تم تقديم Guttenberg في شكله الحالي ، فسيتم تشعب WordPress وستموت نسخة Guttenberg.

ربما يكون المحرر الجديد أكثر منطقية إذا كنت تستخدم WordPress لموقع التدوين وأنشأت سمة PHP له ، ولكن في الوقت الحاضر يستخدم الكثير من الأشخاص WordPress كنظام إدارة محتوى لبناء تطبيقات الويب باستخدام React و PODS / ACF و WordPress REST API. ومن هنا تأتي الحاجة إلى دعم مربعات التعريف وحقول العلاقة للربط المتقدم بين CPTs.

أولاً ، أعتقد أن جوتنبرج سيكون رائعًا.

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

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

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

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

لماذا لا يمكن عرض مربعات التعريف القديمة في المواقع (السياق) التي تم تسجيلها من أجلها وتستمر في العمل كما تفعل حاليًا؟

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

بالطبع ، سيتم تصميم مربع التعريف القديم تمامًا مثل مربع إعدادات النشر الجديد ، كل شيء سيبدو متكاملًا جيدًا.

ربما يتطلب الأمر برنامج نصي legacy-meta-box.php يتم تحميله عند الحاجة ، على سبيل المثال عند استدعاء add_meta_box.

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

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

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

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

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

بشكل عام ، لا يبدو أن معظم الحلول التي يتحدث عنها الأشخاص تتمتع بأي مرونة من شاشة التعديل الحالية.

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

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

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

avocadesign - شرح جيد. لا يعتبر post_content دائمًا محور تركيز المنشور وتعد "الأحداث والفنانين" مثالاً جيدًا. سيكون من الرائع رؤية بعض لقطات الشاشة التي تعرض الواجهة الخلفية والواجهة الأمامية لأنواع المنشورات هذه حتى نتمكن من مساعدة المطورين على تصور كيفية استخدام WP كنظام CMS ، وكيف يعمل العميل العادي من خلال شاشة تحرير المنشور.

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

إذا فكرنا فقط في حلول meta box الحالية على أنها "قديمة" ونطلب منهم استخدام المحرر القديم

في ما اقترحته (فوق تعليقك) ، يتم وضع المربعات الوصفية "القديمة" إما تحت محرر Gutenberg (إذا كان نوع المنشور يحتاج إلى ذلك) أو ضمن مجموعة Post Settings (حسب السياق الذي تم تسجيلهم فيه). لا أرى أي متطلبات للاحتفاظ بالمحرر القديم.

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

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

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

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

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

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

يمثل هذا النوع من واجهة المستخدم العديد من مواقع WordPress المخصصة حيث تحتوي سلسلة من الحقول المخصصة على مزيج من المحتوى على الصفحة وبيانات التعريف "غير المرئية" المستخدمة لتنظيم المشاركات.

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

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

يحتاج المجتمع إلى معرفة ما يحدث لهذا النوع من الواجهة بمجرد تقديم Gutenberg

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

أعتقد أن حالة الاستخدام التي تقدمها والحالة التي

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

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

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

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

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

الأشياء الجيدة تأتي من جوتنبرج وليس الصداع!

فيما يلي شاشة تحرير الأحداث للموقع المذكور أعلاه مع حقول ACF أعلى post_content ثم مربع التعريف القياسي لتقويم الأحداث أسفل post_content.

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

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

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

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

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

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

من المرجح أن يشترك Gutenberg في CPTs ، تمامًا مثل الطريقة التي لا تعلن بها CPT عن دعم المحرر الحالي.

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

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

لا يتخطى Gutenberg واجهة الإدارة في WordPress ، إنه يستبدل وظيفة المحرر ...

هذا غير دقيق. كما هو موجود اليوم ، Gutenberg _is_ هو بديل ملء الشاشة لشاشة تحرير النشر.

@ BE-Webdesign & kevinwhoffman

أيضًا لماذا يجب أن يفوت CPT جوانب Gutenberg التي من الواضح أنها أفضل من شاشة التحرير الحالية؟

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

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

IMHO أن مجرد تمتص عادي.

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

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

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

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

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

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

أيضًا لماذا يجب أن يفوت CPT جوانب Gutenberg التي من الواضح أنها أفضل من شاشة التحرير الحالية؟

لم يقل أحد أنهم على حد علمي؟ لا يوجد فرق كبير بين إضافة دعم المحرر لـ CPT وإضافة دعم لمحرر الكتلة.

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

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

لم يقل أحد أنهم على حد علمي؟ لا يوجد فرق كبير بين إضافة دعم المحرر لـ CPT وإضافة دعم لمحرر الكتلة.

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

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

تعديل:
ما أعنيه بـ "المدى القصير" هو إطلاق الإصدار 5.0 للجمهور ، ويبدو أن أوائل عام 2018 هو الهدف هنا. على المدى الأطول في غضون عامين أو ثلاثة أعوام ، يمكنني رؤية حل هذا الأمر بنجاح أكبر.

BennyVL & dmccan المرونة هي المشكلة الرئيسية هنا. صححني إذا كنت مخطئًا ولكن لا شيء مما أراه يقترحه المطورون الذين يعملون على هذا الأمر مرن مثل ما لدينا حاليًا.

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

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

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

هذا هو الهدف وما يريده معظم الناس.

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

اهلا ياجماعة،

أنا المطور الرئيسي لـ Carbon Fields وأردت إضافة قائمة الإجراءات / التصفية التي نستخدمها والتي قد تتأثر:

المرشحات:

• postbox_classes_{$page}_{$id}

أجراءات:

• init
• admin_menu
• admin_init
• wp
• admin_enqueue_scripts
• in_admin_header
• admin_notices
• admin_print_footer_scripts
• save_post
• edit_comment
• media_buttons
• edit_form_after_title (وضع السكر - ليس حرجًا)

أسئلتي:

• إذا كنا سنحتفظ بمربعات التعريف القديمة ، فكيف سيتفاعلون مع تغييرات البيانات؟
• ما نوع الأحداث (jQuery؟ بعض التنفيذ المكشوف للباعث؟) وما هي الأحداث التي يمكن أن نتوقعها بالضبط من المحرر الجديد (على سبيل المثال ، عند نجاح الإرسال أو الفشل وما إلى ذلك)؟
• هل ستكون هذه الأحداث متاحة لمربعات التعريف القديمة أم فقط لتطبيقات React؟

ملاحظة:
أريد فقط أن أشكر فريق Gutenberg على كل العمل الشاق والجهد وهذا يجعلني متحمسًا لأن WordPress يتجه نحو الأدوات والحلول الحديثة (حتى لو كانت الرحلة تبدو مخيفة)!

دعم الصناديق الوصفية مهم جدًا ...

... للآلاف من مطوري ومستخدمي WordPress.

لا يمكن لـ WordPress تجاهل مشغل البرنامج المساعد الكبير ...

... مثل Advacend Custom Fields Pro (https://github.com/elliotcondon/acf/issues/622) أو WooCommerce أو Yoast SEO.

أنا مسؤول عن مشروع Toolset ، الذي يستخدم أنواعًا

نريد أن نجعل المكونات الإضافية الخاصة بنا متوافقة مع Gutenberg.

هذا ما أفهمه:

• سنحتاج إلى استخدام واجهة برمجة تطبيقات جديدة لعرض الحقول المخصصة والتصنيف على الصفحات والمنشورات ، عند استخدام Gutenberg.
• لا نحتاج إلى فعل أي شيء بخصوص Gutenberg for CPTs ، لأنهم سيستخدمون محرر WordPress العادي وليس Gutenberg.

هل هذا صحيح؟ إذا كان الأمر كذلك ، فهل يمكن أن تحيلني إلى وثائق API لعرض المربعات المخصصة على Gutenberg؟

أعتقد أن المستندات لا تزال تتطور. توجد بعض المستندات على https://github.com/WordPress/gutenberg/tree/master/docs - http://gutenberg-devdoc.surge.sh/

أسمع ما يقوله @ BE-Webdesign وآخرون عن النية لتقليل الاضطراب - شكرًا ، هذا مطمئن - لكنني أردت فقط إضافة قيمتي 5p (حسنًا ، حسنًا ، قيمتي المعتادة 105p).

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

يعد WordPress plus Advanced Custom Fields (Pro) أداة رائعة لإنشاء مواقع ويب مخصصة تعتمد على قواعد البيانات (وحتى أدوات إدارة بيانات الإنترانت) مع واجهات أمامية جذابة وفحص صارم لإدخال البيانات وواجهات مستخدم بديهية ومتسقة وما إلى ذلك. تكون قابلة للتطوير للكميات الهائلة من البيانات العلائقية ، ولكن في كثير من الحالات لا تحتاج إلى أن تكون كذلك ؛ هذه أنظمة بسيطة يمكن إنشاؤها بطريقة فعالة من حيث التكلفة للعملاء. هذا ما يجعل WordPress نظام إدارة محتوى مفيدًا حقًا (وفي الواقع ، نظام RDBMS خفيف الوزن) ، وليس مجرد نظام أساسي للتدوين.

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

1 / سيحتاج المستخدمون النهائيون لدي إلى إعادة التدريب (من السهل علينا ، كخبراء تقنيين ، أن ننسى مدى ارتباك المستخدمين غير التقنيين بشكل كبير من خلال تغييرات الواجهة - لقد كتبت المكوّن الإضافي Clarify Password Reset لأنني كنت أضيع الكثير من الوقت في الفرز المستخدمين الذين أعاقتهم عملية إعادة تعيين كلمة المرور الجديدة المقدمة في 4.3).

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

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

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

تقدم konamac بعض النقاط الرائعة ، وقد قمت بنشر بعضها في موضوع آخر.

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

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

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

3. كل ما يجب أن أكون قادرًا على القيام به في الإرث هو كل ما يجب أن أكون قادرًا على فعله في جوتنبرج.

4. خيارات الشاشة
5. مربعات التعريف (ACF ، Yoast ، إلخ)
6. الروابط الثابتة ؟! لا يمكنني حتى أن أبدأ في فهم سبب عدم إمكانية تعديل هذا في الإصدار 1.0 حتى الآن
7. لا يتم تحميل كتلة المحتوى الكلاسيكية بشكل صحيح في بيئات المضيف المحلي
8. يجب أن تكون الوثائق مفتاحًا لإنشاء مجموعات أنماط مختلفة. أعط عدة أمثلة ، عدة حالات استخدام. ليس كل مطور ثيمات هو الواجهة الخلفية ، لذلك لا تفترض. كن واضحًا تمامًا
9. إعدادات الكتلة بحاجة إلى العمل. من الصعب جدًا معرفة الإعدادات المتاحة لكل كتلة. يبدو عشوائيًا. متى أحتاج إلى تعديل إعدادات الحظر ومتى لا أحتاج؟
10. إن علامات التعليقات الكاملة حول محرر نصوص Gutenberg محزنة.

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

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

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

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

@ BE-Webdesign

عند اكتماله ، سيتم تقديم مربعات التعريف القدير مرة أخرى

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

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

كما هو مذكور في # 2308 ، قمت بنسخ الخطافات التي يستخدمها المكون الإضافي Meta Box عند إنشاء / حفظ الحقول المخصصة:

• يتم وضع الأنماط والنصوص في قائمة الانتظار باستخدام admin_enqueue_scripts . نحن نتحقق من الشاشة الحالية (عبر get_current_screen ) للتأكد من وضع البرامج النصية والأنماط في قائمة الانتظار لتلك الصفحات فقط. بالنسبة للمكوِّن الإضافي الأساسي ، فإنه يتحقق من خلال أنواع المنشورات. بالنسبة للإضافات (مصطلح التعريف ، تعريف المستخدم ، صفحة الإعدادات) ، فإنه يتحقق أكثر من التصنيفات أو صفحة ملف تعريف المستخدم أو صفحات الإعدادات.
• نستخدم أيضًا print_media_templates لطباعة القوالب السفلية.
• تتضمن البرامج النصية التي نستخدمها في المكون الإضافي: منتقي الألوان ، الشرطة السفلية ، العمود الفقري ، نصوص الوسائط ، tinymce (لحقل المحرر)
• نستخدم init لتهيئة جميع الخطافات للمكوِّن الإضافي.
• يتم تسجيل مربعات التعريف باستخدام خطافات add_meta_boxes .
• تستخدم مربعات الميتا المخفية default_hidden_meta_boxes .
• نربط أيضًا بـ post_edit_form_tag للسماح بتحميل الملفات.
• نستخدم save_post_{$post_type} و edit_attachment ، add_attachment لحفظ القيم الوصفية للمشاركات والمرفقات.

ما الخطأ في إنشاء خطافات لعرض مربعات التعريف أعلى / أسفل / الشريط الجانبي لجوتنبرج؟

أعتقد أنني قد أفعل ما يفعله مطورو الطرف الثالث بشكل أفضل ، وألقي مفتاحًا هائلاً آخر في الأعمال.

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

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

ينبع من ذلك الاهتمام الفني بالتداخل فيما يتعلق بالكتل التي لم يتم تخزينها في محتوى post_content. يقول ماتياس إن الكتل ستكون قادرة على التخزين في postmeta ، ولكن إذا كان بإمكان الكتلة تحديد مكان تخزينها ، فكيف سيعمل التداخل ، عندما يقوم أحد الوالدين بالتخزين في postmeta ، ويضيف المستخدم طفلًا يخزن في post_meta مختلف ... (أو في الحالة المرضية ، تحتوي الكتلة المتداخلة التي تخزنها Tha إلى postmeta على كتلة تخزن في نفس حقل postmeta.

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

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

لا توجد إجابة مباشرة للدعم المستقبلي لصناديق التمثيل الغذائي الحالية.

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

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

جوتنبرج رائع. أنا أحب الواجهة والتصميم المرئي وأعتقد أن هذا هو طريق المستقبل من حيث تحرير المحتوى.

أنا سعيد لسماع!

الروابط الثابتة ؟! لا يمكنني حتى أن أبدأ في فهم سبب عدم إمكانية تعديل هذا في الإصدار 1.0 حتى الآن

لأن واجهة برمجة تطبيقات REST لا تدعم هذا حتى الآن. نرحب بأي مساعدة: https://github.com/WordPress/gutenberg/issues/1285

لقد قلت مرارًا وتكرارًا أننا سنقوم بحساب مربعات التعريف.

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

لقد قلت مرارًا وتكرارًا أننا سنقوم بحساب مربعات التعريف.

mtias اعتذاري ، ربما فاتني

أنا أفهم ما تقوله حول دعم REST API ، وسوف أشاهد موضوع التحديثات.

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

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

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

أقوم حاليًا بإنشاء تطبيق ويب باستخدام ACF مع 10 أنواع منشورات مخصصة لا تستخدم محرر tinymce. أنا أستخدم ميزة العنوان وحوالي 15 حقلاً من حقول ACF في المتوسط ​​لكل CPT.
يمكنك حاليًا الإعلان عن الميزات (مثل المحرر ، المصغر ، المقتطف ، إلخ) التي يدعمها CPT.
هل سيكون من الممكن إخفاء / إزالة كتلة الفقرة "اكتب قصتك" وكذلك رمز "إدراج الكتلة" من شاشة التعديل؟

@ cr101 أعتقد أننا إذا نتخلى عن أداة إدراج الكتلة والكتل من Gutenberg ، ويبدو ذلك منطقيًا بالنسبة لي.

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

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

هل هناك أي خطة مطبقة لدمج حقول التعريف الأساسية المخصصة في Gutenberg؟

مرحبا jawittdesigns ،

أنا متأكد من أن المستقلبات الأساسية (على الأقل معظمها) قد أعيد تنفيذها بالفعل في جوتنبرج! إنها تتميز ببعض تدفقات العمل اللطيفة حول التعامل مع التصنيفات وما إلى ذلك.

لا يستخدم الجميع WordPress للتدوين. يستخدم الكثير منا WordPress كنظام إدارة محتوى. نقوم حاليًا ببناء تطبيق ويب باستخدام WordPress REST API و ACF. لدينا 10 أنواع منشورات مخصصة ولكل CPT 20 حقلاً مخصصًا وكل CPTs مرتبطة ببعضها البعض عبر علاقات ثنائية الاتجاه باستخدام علاقة ACF وحقول Post Object ومكوِّن ACF Post-2-Post الإضافي.

لا فائدة من Gutenberg في شكله الحالي لأننا لا نستخدم المحرر الحالي. نحن نستخدم فقط مربع نص العنوان لـ CPTs والباقي عبارة عن حقول مخصصة يتم تخزينها في جدول post_meta.

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

يا لها من مشكلة طويلة الأمد كانت هذه!

من خلال دمج # 3345 و # 3554 ، أصبح دعم meta box في حالة يسعدنا الاتصال بها _feature complete_. لاحظ أن هذا يختلف عن _complete_ ، حيث من الواضح أنه لا يزال هناك عمل يتعين القيام به لتحسين تجربة مربع التعريف ، خاصة فيما يتعلق بالتصميم ، ومعالجة JavaScript الأكثر تعقيدًا ، وتحديد قواعد الرجوع إلى المحرر الكلاسيكي.

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

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

مع الاحترام ، يجب أن يكون هذا بعيدًا عن اكتمال الميزة.

coffeeneed إذا كنت تريد أن تكون بنّاءً ، فيرجى فتح مشكلة جديدة بتفاصيل كافية حتى نتمكن من مساعدتك. شكر