إطلاق جوتنبرج بعد الوفاة ، حتى نتمكن من احتضان منتج جوتنبرج

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

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

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

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

ما هو جوتنبرج في الواقع

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

1. جوتنبرج ، الإطلاق ؛
2. جوتنبرج المنتج.

Gutenberg باعتباره "المنتج" هو المكون الإضافي / الوظيفة نفسها. كانت Gutenberg باسم "الإطلاق" هي العملية التي تضمنت التطوير الأولي وإصدار Gutenberg ، وربما بدأت عندما قدم مؤسس WordPress Matt Mullenweg Gutenberg للجمهور الأوسع في يونيو 2017 خلال WordCamp Europe 2017 ، وانتهت في أوائل ديسمبر 2018 عندما كان WordPress 5.0 صدر مع دمج جوتنبرج فيه.

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

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

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

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

سأفعل هذا بالضبط ، من وجهة نظري.

ما الخطأ الذي حدث أثناء إطلاق Gutenberg

في جملة واحدة ، أفسد الفريق الذي يقود العملية الأمر (هذه هي الطريقة المهذبة لقول ذلك).

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

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

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

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

لماذا تبدو الأمور أفضل بكثير الآن

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

تحسين الاتصال

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

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

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

تم تشكيل فريق الفرز للتعامل مع المشكلات المفتوحة

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

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

أصبحت إمكانية الوصول بلا مشكلة

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

الحكم على جوتنبرج بناءً على مزاياه

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

إنني مندهش من أن Gutenberg لا يزال يُقارن بالطريقة السابقة لتحرير المحتوى في WordPress (بشكل أساسي من خلال الرموز القصيرة ، ولكن أيضًا من خلال الرموز القصيرة والأدوات وغيرها) ، بحجة أنه من الصعب الترميز من خلال Gutenberg. قد يكون هذا صحيحًا ، لكنه أيضًا يفتقد النقطة: Gutenberg ليس هنا لتقديم طريقة جديدة لترميز تطبيقنا ، وإنتاج نفس الميزات كما في الماضي ؛ بدلاً من ذلك ، إنه هنا لتحسين ما يمكن القيام به بشكل كبير ، حيث يعرض إضافة ميزات إلى تطبيقاتنا لم يكن من الممكن أن نحلم بها إلا في الماضي. أيضًا ، Gutenberg ليس منشئ صفحات آخر. في الواقع ، فإن مقارنة Gutenberg بـ Divi أو Beaver Builder تفتقد النقطة بالمثل ، لأنها تشبه مقارنة Victorinox بسكين عادي: نعم ، يمكنك إنشاء موقع / صفحة باستخدام Gutenberg (في الواقع ليس بعد ، ولكنه عمل بالفعل في التقدم) ، ولكن هذا مجرد واحد من استخداماته العديدة ؛ هناك العديد من الاستخدامات الأخرى التي تم إخفاؤها في البداية ، ولكن بمجرد سحبها من مقصورتها وفهم كيفية عملها ، سيتم الكشف عن عالم جديد من الاحتمالات. أدناه ، سوف أصف بعضًا من هذه الاحتمالات الجديدة التي يجلبها جوتنبرج إلى الطاولة.

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

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

في هذه المقالة نفسها ، أصف أيضًا كيف يمكن لـ Gutenberg دعم إستراتيجية "الإنشاء مرة واحدة ، والنشر في كل مكان" (المعروفة أيضًا باسم "COPE") ، مما يتيح إنتاج مصدر واحد لحقيقة المحتوى لإطعامه لجميع تطبيقاتنا ، أيًا كان وسيط أو نظام أساسي يتم تشغيله عليه: الويب والبريد الإلكتروني / الرسائل الإخبارية وتطبيقات iOS / Android و VR / AR والمساعدين المنزليين (مثل Amazon Alexa) وغيرها. نظرًا لأنه يجعل إدارة المحتوى الشاملة أبسط بكثير ، فإن COPE يتيح أيضًا خفض تكاليف إنتاج المحتوى لأنظمة أساسية مختلفة. عندما كتبت مقالتي لأول مرة ، كنت أفكر أنه يمكن القيام بذلك. ومع ذلك ، فقد قمت مؤخرًا بتطبيق COPE لـ WordPress ، وهو يعمل مثل السحر! (ترقبوا مقالًا آخر أشرح فيه كيف يعمل بالتفصيل.)

سيوفر الجمع بين COPE و WordPress APIs (WP REST API و WPGraphQL وواجهة برمجة تطبيقات PoP الخاصة بي) سببًا مقنعًا واحدًا لإدارة كل المحتوى الخاص بنا ، لجميع تطبيقاتنا ، من خلال WordPress. سيكون السبب المقنع الآخر هو سهولة استخدام Gutenberg (التي لم تصل بعد بشكل كامل ، ولكن بالوتيرة الحالية للتطوير ، ستصل عاجلاً وليس آجلاً) ، مما يمكّن المستخدم النهائي من إنشاء محتوى مفصل بطريقة بسيطة للغاية.

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

بالإضافة إلى ذلك ، يسمح Gutenberg بإعادة استخدام الكود مع أنظمة CMS أو أطر عمل أخرى (مثل Drupal و Laravel) ، بحيث لا يحتاج ترميز WordPress إلى أن يقتصر على WordPress بعد الآن ، مما يسمح لنا مرة أخرى بتخفيض تكلفة تطوير مكتبة يحتاج إلى العمل في أكبر عدد ممكن من الأنظمة (على سبيل المثال ، يمكن لشركة توفر تكاملًا لواجهة برمجة التطبيقات الخاصة بها للعديد من المنصات واللغات المختلفة ، مثل Stripe ، الاستفادة منها). حاليًا ، يبدو أن رمز جانب العميل (JavaScript و CSS) فقط يُعاد استخدامه ، ومع ذلك ، يمكن أيضًا إعادة استخدام كود PHP من جانب الخادم. (سأقوم ، مرة أخرى ، بنشر مقال قريبًا عن Smashing لشرح كيفية القيام بذلك.)

هذه الميزات هي بالفعل حقيقة واقعة ، ويمكننا أن نتوقع من Gutenberg تقديم العديد من الأسباب المقنعة لوجودها في السنوات القادمة (وفقًا لما قاله Matt Mullenweg ، قام Gutenberg حاليًا بتنفيذ حوالي 10 ٪ فقط من إمكاناته).

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

خاتمة

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

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