Gutenberg: طريقة لتعطيل محرر جوتنبرج في التعليمات البرمجية؟

أنظر أيضا:

• https://github.com/WordPress/gutenberg/blob/master/docs/faq.md#will -i-be -able-to-opt-out-of-gutenberg-for-my-site
• https://wordpress.org/plugins/classic-editor/

مرحبًا aduth تم تحديث العنوان ليكون أكثر منطقية - البحث عن خيارات رمز :) شكرًا

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

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

هل يمكنك توضيح سبب حاجتك لتحقيق ذلك عبر الكود؟

إذا كانت مشكلة تتعلق برؤية العميل / تحكمه ، فيمكنك دائمًا تثبيت المكون الإضافي المذكور أعلاه على أنه "يجب استخدام البرنامج المساعد": https://codex.wordpress.org/Must_Use_Plugins

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

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

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

لماذا لا يمكن أن تكون وظيفة المكون الإضافي جزءًا من النواة؟ فقط أسأل كما أنا فضولي :)

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

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

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

2 سنتي.

أعتقد أن الاختلاف "نفسي" فقط. إن وجوده في Core يعني أننا سنحصل عليه إلى أجل غير مسمى مما يضر بتبني Gutenberg حيث يعني وجوده كمكوِّن إضافي أننا سندعمه لبعض الوقت (أعتقد أن Matt قال عدة سنوات) وفي مرحلة ما سنتوقف.

لا أعرف ما إذا كان هذا يحتاج إلى فصل في مشكلة منفصلة أم لا ، لكني أود التعبير عن دعمي لفكرة للتثبيتات الجديدة لـ WordPress 5.0 ،

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

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

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

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

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

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

يبدو أن المرشح في WP core أو ثابت لـ wp-config.php ، كخيارين صلبين يمكن الحصول عليهما.

صدى rosswintle ومنشور مدونته الممتاز المرتبط أعلاه: نحن واحدة من العديد والعديد من الوكالات التي تستخدم الحقول المخصصة ، وصناديق التعريف (على وجه الخصوص ACF) لتقديم تجربة تحرير غنية حقًا. كان "WordPress as platform" هو الوعد ، وهذا ما كنا نفعله جميعًا خلال السنوات القليلة الماضية.

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

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

أحب أن أردد صدى مشاعر @ smp303 و @ dmje وrosswintle.

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

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

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

أرغب في تكرار هذا أيضًا - أود أيضًا خيار تعطيل محرر Gutenberg عبر الكود وليس عبر المكون الإضافي.

راجع أيضًا بطاقة Trac هذه التي تم إنشاؤها ، وأغلقت الآن كـ wontfix : # WP43068

لكل dd32 @ في https://core.trac.wordpress.org/ticket/43068#comment : 6

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

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

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

أعتقد أنه يمكننا إغلاق هذا بأمان كـ wontfix ، وقد يتغير ذلك لاحقًا (وسنعيد زيارته بعد ذلك) ، لكنني لا أتوقع أن يحدث ذلك.

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

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

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

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

وبالمثل ، هناك نقاش حول إضافة علامة مشابهة لـ CPT (# 2457) ، بحيث يمكن لـ CPT التي لا تتطلب وظيفة محرر الكتلة إلغاء الاشتراك فيها.

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

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

• يستخدم Customiser مفهوم الكتلة لكل شيء. بالنسبة لـ 99٪ من المواقع الجديدة ، فإن الكتل هي الشيء الوحيد المطلوب لإنشاء مواقع كاملة. التلاعب بالحظر هو كيفية بناء المواقع.
• ستتطور السمات الجديدة حول مواقع البناء بالكامل من الكتل. تم بناء تجربة مستخدم WordPress القياسية باستخدام الكتل.
• في الوقت نفسه ، سيبدأ wp-admin في اعتماد واجهة تطبيق JavaScript التي يجلبها Gutenberg. لا يزال التبديل إلى المحرر الكلاسيكي ممكنًا بالطبع ، لكنه لا يتطابق مع باقي واجهة WordPress.

سأكرر أن هذا على مدار عدة سنوات ، سيكون هناك مكونات إضافية مثل Classic Editor لاستعادة الواجهات القديمة ، ولكن لن يكون من الممكن بالضرورة الحفاظ على هذه الواجهات في Core. في حين أنه سيكون خيارًا معقولًا لتعطيل محرر الكتلة في WordPress 5.0 ، إلا أنك ستلحق ضررًا كبيرًا بعملائك إذا وصلت إلى WordPress 5.5 أو 6.0 ، وما زلت تستخدم المحرر الكلاسيكي. لاختيار مثال واحد ، بقدر ما تطورت أفضل ممارسات تخطيط الموقع من تخطيطات الجدول ، إلى العديد من التكرارات لتخطيطات CSS ، والآن تخطيطات الشبكة ، تتطور أفضل ممارسات تطوير WordPress أيضًا.

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

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

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

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

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

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

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

لا يريدون أن يكتبوا في كتل! لا يريدون محررًا قائمًا على الكتلة! جميعهم يكرهون ذلك - يريدون أن يعمل مثل MS Word أو Google Docs ، لأن هذا هو ما يستخدمونه عادةً لكتابة الأشياء. هذا ما يريدونه.

كيف يمكنني إعطاء ذلك لهم عندما يكون كل ما يريد WordPress القيام به هو دفع الكتل في حلقهم؟

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

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

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

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

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

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

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

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

أنا شخصياً مندهش للغاية من أن المعنى الضمني هنا وفي أي مكان آخر هو أن المحرر الكلاسيكي ستتم إزالته من WP وسيضيفه المكون الإضافي "Classic Editor" مرة أخرى. هل هذا فهم صحيح؟ تبدو هذه فكرة سيئة حقًا بالنسبة لي ، لكن لا يمكنني توضيح السبب في الوقت الحالي.

يوضحmarkkap أيضًا نقطة جيدة حول أداة النص و wp_editor API - كيف سيتم الاحتفاظ بها في جوهرها إذا تمت إزالة TinyMCE؟

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

كنت ستلحق ضررًا كبيرًا بعملائك إذا وصلت إلى WordPress 5.5 أو 6.0 ، وما زلت تستخدم المحرر الكلاسيكي

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

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

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

انت قلت:

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

هذا يخيفني قليلاً وسأعود إليه.

لا يبدو أن صفحة Gutenberg على https://wordpress.org/gutenberg توافق على هذا الوصف. يطلق على الحظر "كتل المحتوى" ويوضح ما يلي:

[كتل] هي طريقة موحدة لتصميم المحتوى

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

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

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

لذلك أعتقد أننا بحاجة إلى توضيح حول طبيعة "الكتلة".

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

البيانات الوصفية في WordPress هي كما هو موضح: بيانات حول البيانات. إنها معلومات تعطي خصائص إضافية لعناصر المحتوى. البيانات الوصفية ليست محتوى. و IMO ، ليست مناسبة للوضع في "الكتل" كما أفهمها بعض أنواع المنشورات التي أقوم بإنشائها لا تحتوي على محتوى بخلاف العنوان: فهي تحتوي فقط على خصائص / حقول / بيانات تعريف.

إذا كان ما تصفه هنا صحيحًا ، فأنا أتساءل لماذا لا يتم حظر حالة النشر؟ لماذا لا يتم حظر الفئات والعلامات؟ لماذا لا يمثل المقتطف كتلة؟

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

بعض post_meta التي أقوم بإنشائها هي نفسها.

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

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

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

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

إضافة +1 لجعل Gutenberg تجربة التحرير الافتراضية لعمليات التثبيت الجديدة فقط.

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

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

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

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

لم أكن أرغب في أن تضيع مسألة تشغيل Gutenberg للتثبيتات الجديدة في هذا القلق الصحيح أيضًا بشأن سهولة التعطيل. إليك مشكلة محددة لها https://github.com/WordPress/gutenberg/issues/4423

يرجى إضافة أفكارك وتصويتك وردود الفعل على ذلك. joffffwpmarkrosswintlemarkkapdmje

بقعة على crosswintle.

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

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

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

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

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

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

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

ومع ذلك ، فإن هذا النهج غير متوافق تمامًا مع تحريك WordPress نحو نهج بناء المواقع ، والذي يحتاجه Automattic إلى WordPress.com لمواصلة المنافسة ضد أمثال Squarespace و Wix et al.

لا يمكن أن يكون WordPress منشئ مواقع ونظام إدارة محتوى احترافيًا في نفس الوقت. لا يمكن فعل ذلك. لقد سار في خط رفيع بين الاثنين ، مما يسمح للمستخدمين بتحريكه في أي اتجاه من خلال المكونات الإضافية. (نحو بناء موقع باستخدام Beaver Builder و Divi et al ونحو نظام إدارة محتوى احترافي مزود بمكونات إضافية مثل ACF و CMB). ومع ذلك ، من الواضح الآن أن نظام إدارة المحتوى يتحرك بثبات في اتجاه بناة الموقع. المواقع التي تستخدم الحقول المخصصة ملعونه.

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

أعتقد أنه مؤشر على العديد من المشكلات التي يجب على فريق WordPress معالجتها أولاً قبل النظر في أشياء مثل Gutenberg:

• تحديث النسخة الصغرى من PHP
• تنفيذ البيانات الدلالية الأصلية (من خلال الحقول المخصصة) وتعديل بنية قاعدة البيانات لحسابها.

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

لا فائدة من تكرار آرائي ، فقد تم التعبير عنها بالفعل أعلاه. أنا أتفق مع الإجماع العام - يجب أن يكون خيارًا مدروسًا لتمكين Gutenberg ليس إلزاميًا في الانتقال من 4.x إلى 5.0.

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

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

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

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

إذا كانت شركة Automattic غير راغبة في تغيير استراتيجيتها المتعلقة بـ Gutenberg - ولنكن صادقين ، فسيكون هذا هو الشيء الصحيح الذي يجب فعله - فإن الخيار الآخر الوحيد هو إنشاء 4.9 إصدار LTS.

بهذه الطريقة ، يمكن تطبيق تصحيحات الأمان على 4.9 للسنوات الخمس القادمة - لنقل -. هذا متسع من الوقت لمطوري مواقع الويب لترحيل مواقعهم إلى Gutenberg أو بعيدًا عن WordPress تمامًا (والذي أعتقد أنه سيكون الخيار الأكثر شيوعًا).

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

أنا شخصياً مندهش للغاية من أن المعنى الضمني هنا وفي أي مكان آخر هو أن المحرر الكلاسيكي ستتم إزالته من WP وأن المكون الإضافي "Classic Editor" سيعيد إضافته.

هذا ليس صحيحا. لقد ذكرت في تعليقي السابق أن المربعات الوصفية و CPTs يمكن أن تعود إلى المحرر الكلاسيكي تلقائيًا - لن يكونوا قادرين على فعل ذلك إذا تمت إزالة كود المحرر الكلاسيكي. 🙂

يستخدم Gutenberg TinyMCE لتشغيل كتل النصوص القابلة للتحرير - وهذا لن يحدث في أي مكان. يمكن الحفاظ على وظائف مثل wp_editor() بسهولة نسبيًا في Core دون الحاجة إلى نقلها إلى مكون إضافي - أتوقع استمرارهم في العمل إلى أجل غير مسمى.

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

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

لذلك أعتقد أننا بحاجة إلى توضيح حول طبيعة "الكتلة".

بالتأكيد. الكتلة هي كتلة من HTML تتلاءم مع الكتل الأخرى. هناك مجموعة من واجهات برمجة التطبيقات التي تجعل العمل مع الكتل أمرًا رائعًا وسهلاً ، ولكن هذا ما يعود عليه الأمر.

كتلة _ليس _:

• كتلة HTML مخزنة في post_content (على الرغم من أن بعض الكتل تستخدم طريقة التخزين هذه).
• ثابت (على الرغم من أن بعض الكتل).
• يتم إنشاؤها ديناميكيًا (على الرغم من وجود بعض الكتل الأخرى).

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

إذا كان ما تصفه هنا صحيحًا ، فأنا أتساءل لماذا لا يتم حظر حالة النشر؟ لماذا لا يتم حظر الفئات والعلامات؟ لماذا لا يمثل المقتطف كتلة؟

مجرد اقتراح ولست متأكدًا مما إذا كان أو يجب أن يكون خيار سمة ولكن لماذا لا يكون ضمن add_theme_support () حيث أن معظم الوظائف المطورة حديثًا كانت في الماضي؟

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

بالنظر إلى إصدار WordPress 3.7 منذ ما يزيد قليلاً عن 3 سنوات ، وكان أحدث إصدار أمني له منذ 6 أسابيع ، أعتقد أنه من المعقول افتراض أن WordPress 4.9 سيحصل على تصحيحات أمان لفترة طويلة قادمة.

eirichmond : قد تكون هناك حاجة إلى add_theme_support() لتركيز تخصيص Gutenberg ، ولكن معظم السمات ستدعم المحتوى المستند إلى محرر الكتلة دون أي تعديلات.

قد تكون هناك حاجة إلى add_theme_support () لتركيز تخصيص Gutenberg ، ولكن معظم السمات ستدعم المحتوى المستند إلى محرر الكتلة دون أي تعديلات

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

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

ما هو بالضبط التركيز على تخصيص جوتنبرج من فضلك؟ ماذا يعني ذلك؟

تحدث مات عن ذلك في "حالة الكلمة" - المحاور الثلاثة لهذا العام هي:

• محرر جوتنبرج
• تخصيص جوتنبرج
• موضوع جوتنبرج

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

هل يمكنك توضيح لماذا لا يدعمها الموضوع؟

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

هل يمكنني تذكير الناس بأن Gutenberg ليس مشروعًا آليًا ، ولا يتيح لي التقليل من قيمة جهود وعمل غير أخصائيي التشغيل الآلي الذين يساهمون

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

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

لكن على أي حال ، لنكن بناءين:

قمت بالترقية إلى WP 5.0 واستبدلت Gutenberg المحرر المخصص الخاص بي / لا أحبه / أحتاج إلى مزيد من الوقت مع العملاء

ماذا أفعل؟

قم بتثبيت البرنامج المساعد الكلاسيكي للمحرر وقم بتمكينه ، تم حل المشكلة. الآن تم استبدال Gutenberg بالمحرر الكلاسيكي الموجود لدينا في 4.9

سلبيات؟

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

لدي الكثير من مواقع العملاء ، وأنا لا أقوم بالتثبيت والتفعيل على كل موقع ، فماذا لو تم إلغاء تنشيط العميل؟

استخدمه كمكوِّن إضافي MU:

• ضع مجلد البرنامج المساعد في wp-content/mu-plugins
• ضع ملفًا في المجلد mu-plugins الذي يحتوي على ما يلي:

<?php
require( 'classic-editor/classic-editor.php' );

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

دروس من البرنامج المساعد الكلاسيكي للمحرر

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

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

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

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

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

@ بينتو بالتأكيد:

مثال البلد:

نوع المنشور "البلد" الذي له اسم (عنوان) ووصف (محتوى) ، ثم:

• تعداد السكان
• عنوان URL لصورة العلم
• الترتيب (وعوامل أخرى ، ربما مشفرة بطريقة ما)
• "المنتديات" ذات الصلة (العلاقات مع مشاركات من نوع آخر)

انظر: http://peoplesunderthreat.org

مثال عقاري:

نوع "خاصية" يحتوي على:

• السعر
• نوع
• عدد الغرف
• تاريخ البناء
  إلخ

مثال حدث:

نوع "حدث" يحتوي على:

• تاريخ
• زمن
• تفاصيل التكرار
• موقعك
  إلخ

هناك الكثير.

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

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

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

جميع الحجج التي رأيتها تجادل بأن الناس لا يحبون Gutenberg ، أو أن لديهم سير عمل تم إعداده بالفعل

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

والمطورين يريدون فقط خيارات للقيام بذلك. يمكنني التبديل بين الميزات الرئيسية الأخرى مثل تصحيح الأخطاء ومحررات التعليمات البرمجية والمواقع المتعددة والتحديثات التلقائية ونشر المراجعات في ملف wp-config.php. يتم تمكين بعض الميزات فقط من خلال السمات التي تدعمها باستخدام add_theme_support . لماذا لا تتوفر لدينا خيارات في التعليمات البرمجية لتبديل Gutenberg بنفس الطريقة بحيث يمكن للمطورين استخدام سير عمل يناسبهم لمثل هذا التغيير الكبير؟

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

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

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

أنا أحب هذه السابقة.

هذا ما يتم الحديث عنه في # 4423

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

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

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

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

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

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

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

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

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

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

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

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

إنه مثل ما قاله الدكتور العظيم كوكس ذات مرة.

ساعدنى لأساعدك.ساعدنى لأساعدك.ساعدنى لأساعدك.ساعدنى لأساعدك.

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

@ smp303 ليس المكان المناسب لمناقشة هذا الأمر ، لكننا نعمل على التوافق مع WooCommerce + Gutenberg الآن. راقب مدونة مطوري WooCommerce .

ربما يكون أفضل تشبيه من "نيو كوكاكولا" هو Windows 8.

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

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

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

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

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

من وجهة نظر منطقية ، أحاول أن أفهم فلسفة السماح للمطورين بالإعلان عن ملف تعريف ، داخل add_meta_box () لعدم دعم Gutenberg الذي يتسبب بعد ذلك في شاشة المحرر ، في أي مكان يتم فيه استخدام ملف التعريف ، لإظهار "الإصدار الكلاسيكي" من شاشة المحرر. لماذا إذن يعارض بعض المطورين الثابت المحدد في ملف wp-config.php؟ إذا كان بإمكاني إعلان عدم استخدام عناصر Gutenberg في منطقة واحدة من التعليمات البرمجية ، فلماذا لا يمكننا الإعلان عن استخدامها في مناطق أخرى مثل تعييننا حاليًا لبيانات التعريف؟

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

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

لا تنس أنه لا يزال بإمكانك تثبيت المكون الإضافي وإعداده في الإصدار 4.9 تحسبًا لوصول Gutenberg.

أعتقد أنه إذا لم يوفر Automattic / WordPress

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

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

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

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

tomjn انتظر! فهل تقول أن نظام الميتا بوكس ​​يتم تجريده من القلب؟

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

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

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

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

إذا كان كل شيء في Classic لا يزال في جوهره ، فلماذا يتم إنشاء مكون إضافي لتنشيطه فقط؟

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

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

جوتنبرج هو طفل مات كثيرًا ؛ كما هو Automattic. لقد قاد المشروع. لقد كان أكبر مشجع لها.

تتمتع Gutenberg بفوائد تشغيلية جادة لـ Automattic - وهي إعطائها منتجًا لتسوية إحساس اللعب مع أكبر منافسيها. لا يمكن قول الشيء نفسه بالنسبة لبقية المجتمع.

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

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

عانت العديد من مشكلات الضغط الأخرى أيضًا من نفس المصير - مثل دفع إصدار min-PHP إلى شيء لم ينته عمره لأكثر من 7 سنوات .

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

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

لا أرى مدى صلة ذلك بالتذكرة؟

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

القوة الدافعة وراء هذا القرار هي أجندة Matt and Automattic لزيادة حصتها في السوق في مساحة موقع الويب DIY. من الواضح أن مخاوف المجتمعات لم تتم معالجتها بسبب تأثير Matt's و Automattic على المشروع. هذا هو المكان الذي يأتي منه 100 ٪ من المجتمعات الإحباط بشأن جوتنبرج.

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

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

اعتبارًا من Gutenberg والإصدار القادم ، يعد WordPress أحد منتجات Automattic. تصديق أي شيء آخر هو حماقة. لا يهم .Com أو .Org - برنامج WordPress هو الآن أحد منتجات Automattic. المطورين ومثل هؤلاء الذين يعملون عليها الآن ليسوا أكثر من متدربين بدون أجر لشركة Automattic.

يريد المجتمع Gutenberg كمكوِّن إضافي. مات لا. مات هو رئيس شركة Automattic. مات هو القائد المعين ذاتيًا لهذا الإصدار. الأشخاص الذين يقودون تطوير Gutenberg هم موظفون في Automattic. مات يجبر هذا. لا يوجد قرار أو مناظرة أخرى - لديه 51٪ من الأصوات وهو يمارسها.

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

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

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

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

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

آخر مشاركة كانت حول موضوع الطلب الذي تم إجراؤه بواسطة wpstudio و jawittdesigns

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

هل لم يتم إهمال ثابت؟ (سؤال حقيقي) يبدو أن WPLANG ربما كان في الإصدار 4.0؟ هل هذا فلسفي عن طبيعة الثوابت؟ هل سيكون المرشح أفضل؟ هل سيكون المرشح مقبولاً لدى @ smp303 ؟

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

لماذا هذا؟

يسأل jawittdesigns بحق:

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

و pento استبعد إلى حد كبير

يستخدم Gutenberg TinyMCE لتشغيل كتل النصوص القابلة للتحرير - وهذا لن يحدث في أي مكان. يمكن الحفاظ على وظائف مثل wp_editor () بسهولة نسبيًا في Core دون الحاجة إلى نقلها إلى مكون إضافي - أتوقع استمرارها في العمل إلى أجل غير مسمى.

أخيرا:

لا تنس أنه لا يزال بإمكانك تثبيت المكون الإضافي وإعداده في الإصدار 4.9 تحسبًا لوصول Gutenberg.

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

rosswintle - من المهم مناقشتها لأن معرفة من يتخذ القرارات في النهاية تلقي الضوء على مدى احتمال قبول

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

على أي حال. قمت بعمل بعض النقاط الجيدة في آخر وظيفة. في الواقع ، دعني ألتقط عرض الأسعار الخاص بك:

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

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

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

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

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

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

لا أشعر أن هناك ما يكفي من التفكير في هذا الأمر ، ولهذا السبب يعتبر المكون الإضافي هو الحل النهائي.

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

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

wpstudio هذا ما يطلبه # 4423 إلى حد كبير.

مثل rosswintle ، أعتقد أنه من المهم إعادة هذه المشكلة إلى المسار الصحيح لأولئك الذين

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

آمل أن تعود هذه المسألة إلى مسارها الصحيح وأن تواصل مناقشة هذه المسألة باحترام.

@ karmatosed و ntwb و @ tomjn وآخرين في هذا الموضوع ، إذا كان صراختي الصغيرة أعلاه تثير الإساءة ، فأنا أعتذر عن ذلك. هذا موضوع مهم للغاية ويستحق المناقشة - إذا كنا سنناقشه بالفعل.

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

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

السؤال هو "لماذا؟"

أستطيع بالتأكيد أن أرى السبب وراء إجبار جوتنبرج على أن يكون في Core. أعتقد أن "الكتل" مهمة جدًا للبقاء في المستقبل والاستخدام الواسع النطاق لـ WordPress أو .org أو .com. أنا افعل. أنا خلف "الكتل" بنسبة 100٪.

ومع ذلك ، لا أعتقد أن جوتنبرج نفسه ، باعتباره طريقة توصيل تلك "الكتل" ، هو نظام مدروس جيدًا. من هذا الموضوع فقط ، هناك 3 حالات استخدام مختلفة (أنا و rosswintle و @ smp303 ) ولا يبدو أن جوتنبرج يرضي أيًا منا. في الواقع ، إنه يسبب لنا قدرًا كبيرًا من القلق - بالنسبة لنا ولأعمالنا ومستخدمينا.

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

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

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

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

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

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

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

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

و @ karmatosed ، أنت محق 100٪ في أن قسم "المشكلات" في Github ليس أفضل مكان لإجراء هذا النقاش. أوافق على أن هذا الريبو يجب أن يُترك إلى حد كبير للغرض المقصود منه ، وهو تحديد وحل المشكلات الفنية المتعلقة مباشرة ببرنامج Gutenberg الإضافي.

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

هل سيتم إنشاء موقع لمناقشة جوتنبرج؟ ليس فقط تنفيذه ولكن للتعليق ومناقشة الواجهة؟ الجدول الزمني للإفراج؟ (على سبيل المثال ، ما هي المعايير التي تحكم ما إذا كان Gutenberg و WP5.0 "منتهيين" وجاهزين للإصدار؟ من يتخذ هذا القرار؟ ") هل سيكون هناك اختبار للمستخدم لواجهة Gutenberg؟ هل هناك طريقة لجمع البيانات والتعليقات من @ tomjn الصورة مفيدة جدا "Frontenberg"؟ إذا كان الأمر كذلك، وسيتم نشر هذه البيانات؟

كان هناك مقطع فيديو مثير للاهتمام على YouTube يطلب من الأشخاص تجربة استخدام Gutenberg وتقييم حدسيته (الرابط هنا: https://youtu.be/7iWRBLCP-l0) - هل هناك أي أشخاص آخرين مثل هذا؟ هل هناك جهد كبير لاختبار جوتنبرج؟ إذا كان الأمر كذلك ، فأين يتم الاحتفاظ بهذه البيانات؟ كيف يتم تقاسم هذه البيانات؟ هل يمكن للمجتمع رؤيته؟ هل يتم استخدامه لقيادة التصميم؟

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

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

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

بعد إجراء القليل من البحث حول هذا الموضوع ، يبدو أن كل ما تحتاجه ، في ملف mu-plugin هو التالي لتعطيل Gutenberg بالرمز ، إلا إذا فاتني شيء - وهو أمر محتمل!

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

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

هناك أمران يجب ملاحظتهما في ذلك:

• gutenberg_can_edit_post_type ليس اسم المرشح النهائي - gutenberg ستتم إعادة تسمية الأسماء قبل دمجها في Core.
• يعني هذا الفلتر "عدم تحميل محرر الكتلة" ، ولا يعني "استخدام المحرر الكلاسيكي". إنه يعمل في الوقت الحالي ، لكنه غير مضمون للعمل في المستقبل. نظرًا لأن الكود الخاص بـ Classic (على سبيل المثال ، edit-form-advanced.php ) تم نقله إلى المكون الإضافي Classic Editor ، فسوف يتوقف عن الرجوع إلى المحرر الكلاسيكي ، ويتوقع منك صراحة تحميل المحرر الخاص بك.

rosswintle : التقاط الموضوع من الأسبوع الماضي :

أسهل طريقة للتفكير في هذا الأمر هي "إذا ظهرت البيانات بين <body> و </body> ، فهي محتوى ، وستتوافق في النهاية مع الكتلة". بالنسبة إلى WordPress 5.0 ، يعد هذا محدودًا بدرجة أكبر - فقط ما يأتي بين <article> و </article> هو كتل. 😉

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

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

إذن ماذا عن المعلومات التي لا يتم عرضها على الواجهة الأمامية؟ اسم المالك؟ العلاقات لعرض المواعيد؟ هل هذا "محتوى"؟ هل يتم إدخال ذلك في "كتلة"؟

قد يتم عرض الفئات / العلامات / التصنيفات أو لا يتم عرضها في الواجهة الأمامية. هل هم "كتل"؟

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

قلت سابقا:

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

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

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

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

آمل أن ينقل هذا الارتباك.

إذن حول هذه الطرق لتعطيله ...؟

pento ، لا تشير كتلة doc لهذه الوظيفة على الإطلاق إلى أن هذا المرشح مؤقت:

/**
 * Filter to allow plugins to enable/disable Gutenberg for particular post types.
 *
 * <strong i="7">@since</strong> 1.5.2
 *
 * <strong i="8">@param</strong> bool   $can_edit  Whether the post type can be edited or not.
 * <strong i="9">@param</strong> string $post_type The post type being checked.
 */

ما هو الغرض من هذا المرشح إذا لم يتم القيام به كما هو موضح؟

بالإضافة إلى pento بخصوص هذا:

يعني هذا الفلتر "عدم تحميل محرر الكتلة" ، ولا يعني "استخدام المحرر الكلاسيكي". إنه يعمل في الوقت الحالي ، لكنه غير مضمون للعمل في المستقبل. نظرًا لأنه تم نقل الكود الخاص بـ Classic (على سبيل المثال ، edit-form-advanced.php) إلى المكوّن الإضافي Classic Editor ، فإنه سيتوقف عن الرجوع إلى المحرر الكلاسيكي ، ويتوقع منك صراحة تحميل المحرر الخاص بك.

لقد تم إخبارنا في عدد من الأماكن أنه إذا كانت أنواع المنشورات تعلن عن show_in_rest => false أو أن مربع التعريف على شاشة تحرير المنشور يعلن عن '__block_editor_compatible_meta_box' => false, ، فسيتم تحميل المحرر الكلاسيكي. يبدو أنك تقول من الأعلى أن هذا لن يكون جزءًا من النواة ، وبالتالي كيف يمكن أن يكون هذا هو الحال أنك لم تقم بتنشيط المكون الإضافي للمحرر الكلاسيكي؟

للرجوع إلى المحرر الكلاسيكي ، هل تم اكتشاف شيء لا يدعم Gutenberg ، فمن المؤكد أن المحرر الكلاسيكي يجب أن يظل جزءًا من النواة - لذلك بالتأكيد لسنا بحاجة إلى المكون الإضافي لاستدعاء هذه الوظيفة؟

إذن ماذا عن المعلومات التي لا يتم عرضها على الواجهة الأمامية؟ اسم المالك؟ العلاقات لعرض المواعيد؟ هل هذا "محتوى"؟ هل يتم إدخال ذلك في "كتلة"؟

من المؤكد أن هناك مجالًا للمعلومات الوصفية أيضًا - تمت مناقشته في # 3330. الشيء الأساسي الذي أردت ملاحظته هو أن الكثير مما يشار إليه باسم "البيانات الوصفية" هو في الواقع محتوى.

قد يتم عرض الفئات / العلامات / التصنيفات أو لا يتم عرضها في الواجهة الأمامية. هل هم "كتل"؟

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

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

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

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

إذن حول هذه الطرق لتعطيله ...؟

إذا قمت بإنشاء مواقع ، فاستخدم المكون الإضافي Classic Editor. إذا قمت بإنشاء مكونات إضافية ، فاستخدم علامتي CPT و meta box. 🙂

إذا قمت بإنشاء مواقع ، فاستخدم المكون الإضافي Classic Editor. إذا قمت بإنشاء مكونات إضافية ، فاستخدم علامتي CPT و meta box. 🙂

هذا جيد للمواقع التي نبنيها من الآن فصاعدًا ، أو العملاء الذين لدينا "على الكتب" ونعتني بمواقعهم. ولكن ماذا عن العملاء الذين قمنا ببناء مواقعهم في الماضي وتعمل بشكل جيد ، التحديث التلقائي وما إلى ذلك ، فمن المحتمل أن ينقروا على تحديث إلى WordPress v5.0.

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

wpmark مسمر.

سأستخدم المكون الإضافي Classic Editor إذا احتجت إلى ذلك في المستقبل. سأستخدم علامتي CPT و meta box إذا احتجت إلى ذلك في المستقبل. لكن لدي عشرات الأفراد والشركات والمؤسسات الخيرية / غير الربحية من جميع الأشكال والأحجام التي أنشأت بالفعل مواقع لها. البعض منهم ما زلت على علاقة عمل معهم. انتقل الآخرون وهم إما يديرون الموقع بأنفسهم ، أو يعملون مع مطور آخر أو لا يوجد مطور على الإطلاق.

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

هذه أرض # 4423 حقًا.

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

gutenberg_can_edit_post_type (أو أيًا كان اسمه في Core) و '__block_editor_compatible_meta_box' => false سيعود إلى الواجهة الكلاسيكية في WordPress 5.0. ومع ذلك ، قد تغير إصدارات WordPress المستقبلية هذا السلوك.

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

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

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

راجع # 3902 لمزيد من المناقشة حول هذه القضايا.

فيما يتعلق بموضوع إعلام مالكي المواقع ، لن يتم تحرير WordPress 5.0 في فراغ. هناك العديد من الأدوات التي يمكننا استخدامها لإبلاغ مالكي المواقع بالتغييرات القادمة وإعلامهم بما إذا كانت مواقعهم ستعمل أم لا. ستتضمن إصدارات WordPress 4.9.x المستقبلية معلومات حول محرر الكتلة ، وهناك خطط جارية لجمع البيانات حول توافق البرنامج المساعد (سواء المؤتمتة أو من الجمهور - # 4072) ، ونحن منفتحون على خيارات أخرى للتأكد من أن مالكي المواقع على دراية بها ماذا سيأتي.

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

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

pento لماذا أغلقت هذا؟ لم يتم حل المشكلة بعد.

أنت تثبت فقط النقطة التي لا يستمع إليها المجتمع من خلال إغلاق هذا.

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

كان القرار لا - لن يتيحوا طريقة لتعطيل Gutenberg في التعليمات البرمجية. عليك الاعتماد على البرنامج المساعد.

غير سعيد تمامًا وغير راضٍ عن هذا ولكن على الأقل حاولت.

كان القرار لا - لن يتيحوا طريقة لتعطيل Gutenberg في التعليمات البرمجية. عليك الاعتماد على البرنامج المساعد.

أين ومتى حدث ذلك؟ لا يوجد ذكر لقرار هنا.

أم أن هذا مجرد رد فعل نموذجي للفريق الأساسي من خلال التظاهر بالاستماع ثم إيقافه؟

ما نوع الدقة التي تريدها في هذه المرحلة؟

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

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

من pento - هذا هو سبب إغلاقه

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

أعني أن دعم meta box لا يزال مكسورًا في 2.0 ولست واثقًا من أنه سيعمل على الإطلاق في هذه المرحلة.

المكون الإضافي موجود بالفعل: https://wordpress.org/plugins/classic-editor/

للإجابة على السؤال الأصلي لـ @ smp303 .

1. في ملف wp-config.php ، أضف

define( 'ENABLE_GUTENBERG', false );

1. في ملف يسمى my-hacks.php في المجلد mu-plugins ، والذي قد تضطر إلى إنشاء رمز

<?php // (C) Bobbing Wide 2015-2018
if ( defined( "ENABLE_GUTENBERG" ) && !ENABLE_GUTENBERG ) {
    add_filter( 'gutenberg_can_edit_post_type', '__return_false' ); 
}   

الدعائم tomjn @ wpmark

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

ملاحظات: تم تقديم الملف المسمى my-hacks.php في عام 2003 وتم إهماله في 200 مرة.
ولكن لا يوجد شيء يمنعك من تنفيذه كمكوِّن إضافي يجب استخدامه في mu-plugins .

إذا كنت تريد معرفة مدى صعوبة إزالة التعليمات البرمجية المهملة ، بما في ذلك حقل الخيار المرتبط بها
راجع WordPress TRAC # 33741 - إزالة الإشارات إلى my-hacks.php وخيار hack_file

حتى أسهل ... في ملف wp-config.php

$_GET['classic-editor'] = true;

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

داخل المنشور نحتاج فقط إلى محرر نصوص.

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

الآن ووردبريس رائع بسبب المجتمع. 5.0 يعني أن نبدأ من 0. لذا ، مثل أي إطار عمل آخر.

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

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

اجعل مهارات البرمجة لديك للمساعدة في حل المشكلة.

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

انضم إلينا وساعد في تحريك WordPress.org إلى الأمام كأداة لبناء الموقع.

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

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

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

كان طلب سايمون الأصلي إصلاحًا قصير المدى لمشكلة طويلة الأمد.
أعتقد أن عملية ترحيل المحتوى ستستمر لسنوات.

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

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

يحل Gutenberg Manager هذه المشكلة ويسمح على سبيل المثال بمواصلة استخدام Elementor أو Visual Composer أو Siteorigin Builder أو Cornerstone دون أي مشكلة حتى بعد WP 5.0.
من ملاحظات المستخدم الأولى على WP.org ، يبدو أن المكون الإضافي قد تم تقديره :)

لهذا السبب أود أن أقدم لكم مدير جوتنبرج -> https://wordpress.org/plugins/manager-for-gutenberg/

يمكن للمطورين استخدام البرنامج المساعد في السمات والإضافات الخاصة بهم بفضل بعض الروابط المفيدة. هناك رابط لإخفاء لوحة خيارات البرنامج المساعد حتى لا يراها المستخدم النهائي في WP backend (ميزة رائعة للمطورين الذين يريدون تضمين Gutenberg Manager في مشاريعهم).

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

شكرا لكم جميعا على اهتمامكم،
عمل جيد.

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

تأكد من wpmark ،

ألق نظرة على الصف 79 -> https://github.com/unCommonsTeam/gutenberg-manager/blob/master/inc/core.php

الأفضل

unCommonsTeam شكرا

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

ومع ذلك ، فقد أبلغ pento أن ذلك لم يكن حلاً قويًا لأنه أعاد محررًا إلى WordPress. انظر https://github.com/WordPress/gutenberg/issues/4409#issuecomment -357912790

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

الأفضل

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

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

كما ذكر pento :

يعني هذا الفلتر "عدم تحميل محرر الكتلة" ، ولا يعني "استخدام المحرر الكلاسيكي". إنه يعمل في الوقت الحالي ، لكنه غير مضمون للعمل في المستقبل.

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

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

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

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

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

في صحتك

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

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

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

يمكن لـ WordPress.com تشغيل Gutenberg افتراضيًا ، بينما يأتي WP مع إيقاف تشغيله افتراضيًا ، وبالتالي توفير أفضل العوالم للنظام البيئي بأكمله.

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

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

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

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

WebTrooper ، يتم الحفاظ على المكون الإضافي Classic Editor من قبل فريق مطوري WordPress (نفس الأشخاص الذين يحافظون على Core) ويتم صيانة Gutenberg Ramp بواسطة Automattic ، لذلك يجب أن يكون كلاهما محصنًا ضد عوامل "المطور في إجازة" أو "مشغول جدًا"

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

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

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

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

لقد اقترحت دائمًا تشغيله افتراضيًا لعمليات التثبيت الجديدة.

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

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

بدلاً من ذلك ، سيفي 12 أبريل 2020 بالغرض. 😉

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

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

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

أعتقد أنه يجب إيقاف تشغيل Gutenberg لعمليات التثبيت الجديدة أيضًا ، نظرًا للأسباب المهمة التالية:

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

• تعتبر سهولة الدخول هذه مهمة للغاية ، نظرًا لأنها تبدأ بسهولة مثل هذا ، فإن الناس يفهمون أن `` WordPress سهل '' ، ولديهم بسهولة تصور دافئ للمنصة ، وموقف أكثر قبولًا وثقة تجاه تعلمها أكثر

• تتحد كل هذه الأشياء في تصور "WordPress يعمل فقط" ، وهم يوصون به بشكل مريح لأقرانهم. هذه هي الطريقة التي تمكنا بها من النمو لتشمل 30٪ من الإنترنت.

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

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

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

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

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

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

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

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

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

tomjn سأكرر صدى rosswintle هنا بقول نعم لقد اقترحنا أنه يجب تشغيله فقط للتثبيتات الجديدة افتراضيًا - https://github.com/WordPress/gutenberg/issues/4423. هذه قضية أخرى مغلقة ، مغلقة دون مناقشة حقيقية لهذه النقطة.

إنهم ليسوا على استعداد للاستماع ، هناك مكون إضافي ، بلاه بلاه بلاه ، هذا مغلق. تحرك على طول أي شيء لترى هنا. كل شيء عن .com لا أحد يهتم به. org ليس هناك أموال لـ Automatic هناك.

@ smp303 هل يمكنك من فضلك تحديد من هم ؟

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

إنهم ليسوا على استعداد للاستماع ، هناك مكون إضافي ، بلاه بلاه بلاه ، هذا مغلق. تحرك على طول أي شيء لترى هنا. كل شيء عن .com لا أحد يهتم به. org ليس هناك أموال لـ Automatic هناك.

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

في الملاحظة الجانبية: @ karmatosed بما أنك لم تتمكن من الرد والإجابة على سؤالي في أحد التعليقات في منتدى WordPress بخصوص Gutenberg ، أتساءل لماذا يختفي تعليقي فجأة. حركة جميلة!

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

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

يعد المكون الإضافي Classic Editor خيارًا للعودة إلى المحرر الكلاسيكي عبر موقع بأكمله. يتم الإعلان عنه بشكل بارز في إصدار WordPress 4.9.8 القادم كخيار للتثبيت الآن ، استعدادًا لـ WordPress 5.0.

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

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

لتجنب تطور هذا الموضوع بشكل أكبر ، سأقوم بقفله.

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