يحترم Gutenberg دعم المحرر كما هو معلن من قبل CPT ولن يتم تحميله إذا لم يكن ذلك مدعومًا.

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

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

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

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

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

إذا كان هذا يعني أن Gutenberg لا يتم تحميله على الإطلاق ويتم استخدام المحرر الكلاسيكي بدلاً من ذلك ، فهذا يضعنا في مسار نحو مسؤول WP ممزق مقسم بين بيئتي Gutenberg و Classic.

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

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

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

سنحتاج دائمًا إلى واجهة "إدارة" وواجهة "تحرير".

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

ثم ربما ينبغي معالجة زحف النطاق ، ويجب أن يقتصر Gutenberg على المنطقة التي يسكنها wp_editor() . من المؤكد أنه سيحل العديد من مشكلات التوافق.

زحف النطاق

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

تمكين جوتنبرج لكل نوع المنشور

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

إذا لم تستطع معرفة السبب ، فتخيل أنك مطور مكون إضافي جديد يدخل الصناعة بعد عامين من الآن ، بعد دمج Gutenberg.

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

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

show_in_rest

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

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

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

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

على سبيل المثال ، يحتوي موقع المؤلف الذي عملت عليه على CPTs لـ "Books" و "Shop links". إن وجود جوتنبرج كمحرر لصفحات قوائم الكتب أمر منطقي تمامًا. لكن "روابط التسوق" ليس لها منشورات أو صفحات خاصة بها ، ولكنها تستخدم لتوفير منطق الروابط إلى المكتبات على الإنترنت في كل صفحة "كتاب". يعرض قالب صفحة الكتب روابط التسوق لصفحات المنتج التي تطابق المنطقة (مثل المملكة المتحدة والولايات المتحدة) والتنسيق (مثل الكتاب الإلكتروني والطباعة) ، وإدخال رقم ISBN المخزن في حقل التعريف المنشور في بنية عنوان URL لكل متجر عبر الإنترنت - انظر لقطات الشاشة.

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

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

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

على سبيل المثال ، تخيل أنك مطور مكون إضافي وتريد أن يكون مربع التعريف "إعدادات رابط المتجر" متاحًا في نوع منشور واحد يستخدم Gutenberg ونوع منشور ثانٍ لا يستخدمه. عندما تقوم بتوزيع مكون إضافي على آلاف المستخدمين الذين يتوقعون أن يعمل مع أي نوع منشور ، فلن يكون لديك رفاهية الاختيار. هذا عندما تدخل الأسئلة المذكورة في https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341867663.

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

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

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

... كيف يجب أن يتعامل Gutenberg مع CPTs التي لا تدعم المحرر - كيف يعمل Gutenberg في السياقات حيث لا يكون من المنطقي إنشاء صفحة من الكتل ، حيث تكون مدفوعة بالميتا فقط؟

إذا كان جوتنبرج سيتراجع ويحل محل المحرر فقط كما هو الحال في مفهوم Yoast الذي ذكرته في https://github.com/WordPress/gutenberg/issues/3304#issuecomment -341474018 ، فإن تمكين أو تعطيل Gutenberg يصبح واضحًا جدًا.

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

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

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

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

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

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

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

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

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

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

CalebWoodbridge هذا بالفعل كيف يعمل. انظر: https://github.com/WordPress/gutenberg/blob/master/lib/register.php#L290

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

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

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

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

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

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

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

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

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

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

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

إن محاولة التوفيق بين عبارات مثل هذه والبيانات العامة مثل http://matiasventura.com/post/gutenberg-or-the-ship-of-theseus/ تجعل من الصعب جدًا على المستخدمين الشعور بأنهم يتلقون اتصالات صادقة حول العمل جاري تنفيذه. يستخدم WordPress ملايين الأشخاص بملايين الطرق ، وقد تم توضيح أنه ، فيما يتعلق بالجوانب التقنية مثل دعم التمثيل الغذائي أو تنسيق ما بعد التخزين ، يلزم اتباع نهج تدريجي ، مع أقل قدر ممكن من الكسر. أدى هذا القرار إلى تعقيد عدة أجزاء من التنفيذ ، وفرض قرارات دون المستوى الأمثل ولكنها مدعومة بشكل أفضل من نواحٍ عديدة.

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

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

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

من الجيد أن تذكر إصلاح الوسائط كمنطقة تحتاج إلى إعادة صياغة ... وهي منطقة عانت بسبب الإصلاح الجامح وغير المرن. كان هذا هو القسم الأول من WordPress الذي يتبنى بشكل كامل إطار عمل JS ، وكان إلى حد كبير خطوة كبيرة إلى الوراء للمطورين. لا يعد عدم التخصيص في مكتبة الوسائط علامة على أنها مثالية ، بل إنها تفتقر إلى التصميم المدروس الذي يأخذ حالات الاستخدام المستقبلية والحالية في الاعتبار. لقد حاولت تعديل واجهة الوسائط عدة مرات ، فقط لأجد شخصًا ما ، قرر في مرحلة ما أنه يجب ترميز المكونات الرئيسية في قوالب العمود الفقري. لقد واجهت حرفيًا إحدى هذه الحالات بالأمس! (كما ترى في الفقرة السابعة هنا: https://gschoppe.com/wordpress/disable-attachment-pages/)

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

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

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

gschoppe ، شكرًا لك على الوقت الذي

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

ليس من المعقول إبقاء التطوير وفقًا لمعيار واحد والتصميم بمعيار آخر.

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

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

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

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

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

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

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

تعليقي لا يهدف إلى زيادة سماع التصميم

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

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

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

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

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

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

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

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

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

لإضافة القليل من الزيت إلى النيران: في الأسبوع الماضي فقط ، واجهت مشكلة كبيرة في استخدام iFrames ، على سبيل المثال. قد تلعب بشكل جيد على أنظمة سطح المكتب ، ولكن في 90٪ من الحالات التي تم اختبارها ، فإنها تفشل بشكل كبير على الأجهزة المحمولة / المستجيبة. بعد البحث في العديد من سلاسل رسائل لوحة الرسائل ، والمقالات على الشبكة والأسئلة على Stack Overflow ، قررت التخلي تمامًا عن نهج iframe ، لأن الاستجابة تصبح معقدة للغاية مع em .. لاف. كانت بعض مهام التحويل سهلة إلى حد ما ، مثل "استخدام إعادة توجيه إلى النطاق الفرعي الفعلي حيث يوجد المشروع" بدلاً من الاعتماد على iframe لوضع زخرفة لطيفة تُعرف أيضًا باسم المجال الرئيسي المفترض ، ولكن البعض الآخر كان أكثر بؤسًا.

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

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

فقط .02 سنتًا ،
cu، w0lf.

شكرًا لك mtias على إظهار هذه المشكلة.
فيما يلي أقوم بنشر أفكاري حول كيفية قيام Gutenberg بفتح الأبواب لمطوري مكونات WordPress الإضافية.

فئة CSS قابلة للتخصيص لأي كتلة موجودة

مطلوب: فئة CSS لكل غلاف كتلة ووصول كامل لتخصيصه. سيكون رائعًا إذا تطلب Gutenberg فئة CSS على العنصر الأعلى حتى من مطوري الطرف الثالث.

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

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

سمات البيانات القابلة للتخصيص لأي كتلة موجودة

مطلوب: إمكانية إضافة سمات بيانات مخصصة لأي غلاف كتلة.

الغرض: بديل أنظف وأكثر مرونة لفئات CSS المخصصة الموضحة أعلاه. باستخدام سمات البيانات ، يمكننا تصميم أي عنصر على الصفحة. إلى جانب التصميم ، يمكن استخدام سمات البيانات المخصصة لتخزين البيانات الوصفية الإضافية لـ JS.

استخدام المثال:

• الكتل المتجاوبة : ضع علامة على كتلة ليتم عرضها على الأجهزة المحمولة / أجهزة سطح المكتب فقط
• الكتل الشرطية : حدد كتلة ليتم عرضها / إخفاؤها باستخدام JS <div data-condition="if-adblock"... ، <div data-condition="if-from-facebook"...
• حركة الكتلة : ضع علامة على كتلة ليتم تحريكها <div data-animation="on-load animation-style-3"...
• تصميم الكتلة : <div data-skin="dark"...