عمليات الطرح على مراحل لمكوّن WordPress الإضافي ومطوّري السمات: تجنب "إصدار Clusterbug"
نشرت: 2020-12-23هل تتذكر آخر مرة أصدرت فيها إصدارًا جديدًا من مكون WordPress الإضافي أو السمة لتكتشف بسرعة أنك أضفت خطأً رئيسيًا جديدًا عن طريق الخطأ تسللت من خلال تشققات تسلسل الاختبار؟
حطم Yoast SEO 3.0 العديد من مواقع الويب في عام 2015. فعل Elementor 3.0 الشيء نفسه هذا العام. وهذان مثالان فقط من أعلى رأسي في الشركات الرائعة في منطقتنا مع أكثر من 100 موظف وموظفين متخصصين في ضمان الجودة (ولا ، لا يتعلق الأمر بالإصدار 3.0 ، ولكن ربما تكون علامة على تخطي هذا الإصدار في برنامجك ؛ )).
سواء كنت مبرمجًا علميًا أو مهندس برمجيات ، أو مطورًا مستقلًا ، أو جزءًا من متجرًا إضافيًا / متجرًا كبيرًا ، يتعين علينا جميعًا التعامل مع الأخطاء. إنه جزء لا مفر منه من تطوير البرمجيات.
بغض النظر عن أتمتة CI / CD / الاختبار الفاخرة التي تضعها - لن تتمكن أبدًا من اختبارها كلها. عدد تكوينات الخادم (PHP و MySql والتخزين المؤقت وخادم الويب) وإصدارات WP ومجموعات المكونات الإضافية والسمات ... كلها لا حصر لها.
وهذا مخالف للبديهة. كلما زادت شعبية منتجاتك واستقرارها ، زادت فرص إصدار "Clusterbug" المخيف ، والذي سيؤدي إلى استنزاف دعمك ، وقد يؤثر بشكل كبير على ثقة العملاء وولائهم ، وقد يضر بسمعة العلامة التجارية بشكل عام.
بينما لا يمكنك تجنب الأخطاء ، يمكنك وبالتأكيد يجب عليك تخفيف المخاطر بقدر ما تستطيع.
إذا كان لديك هاتف ذكي ، فمن المحتمل أنك لاحظت أن بعض أصدقائك يتلقون تحديثات Android / iOS أيامًا وأسابيع وأحيانًا حتى أشهر قبل الحصول عليها. هذه ليست مصادفة ، ولا ، ليس شيئًا شخصيًا ضدك. إنها عملية نشر تقدمية مقصودة تسمى Staged Rollouts تساعد شركات مثل Apple على شحن تحديثات البرامج الرئيسية لأكثر من مليار جهاز.
نعم ، مليار!
هل يمكنك حتى فهم مقدار المسؤولية التي سيتحملها قائد الإصدار في Apple على أكتافهم إذا اضطروا إلى دفع تحديث مباشر إلى 1.5 مليار جهاز محمول في وقت واحد؟ لا استطيع. أراهن أنه لن يوافق أي رجل عاقل على تحمل مثل هذه المسؤولية.
إذًا ، كيف تعمل آلية الطرح المرحلي؟ كيف يمكنك تنفيذه؟ وماذا ينتظر WordPress.org؟ هذه هي الموضوعات التي سأقوم بتغطيتها أدناه.
ما هي الطرح المرحلي للسمات والإضافات في WordPress؟
تتيح لك عمليات الطرح المرحلي تحديد عدد (أو نسبة) مواقع الويب التي تريد طرح إصدار جديد لها. تتيح لك آلية الإطلاق المرحلي بدء دورة الإصدار مع تعرض محدود ثم زيادتها بشكل تدريجي أثناء مراقبة الدعم والتعليقات ، وبالتالي بناء الثقة في إصدارك لك وللمستخدمين.
ما هي فوائد الطرح على مراحل؟
بدلاً من المخاطرة بقاعدة التثبيت بأكملها بإصدار أخطاء محتملة ، أو تتعارض مع المكونات الإضافية / السمات الخاصة بالجهات الخارجية ، أو حتى مشكلات UI / UX ، يمكنك إصدار إصدارات تدريجيًا ، مما يقلل من عدد الأشخاص ومواقع الويب التي ستتعرض لمشاكل غير متوقعة. بمجرد تسوية جميع المشكلات والأخطاء التي تم اكتشافها أثناء عملية الطرح ، ستتعرض الغالبية العظمى من المستخدمين لديك لإصدار "ناضج" وأكثر استقرارًا.
نستخدم التحديثات المستمرة لضمان جودة إصداراتنا الجديدة. إذا كانت هناك مشكلة في إصدار جديد ، فيمكننا التعرف عليها بسرعة ، وستتأثر فقط مجموعة فرعية صغيرة من المستخدمين.
جون تيرنر ، مؤسس SeedProd
يعد استخدام التدفقات المرحلية أفضل ممارسة لإصدار البرامج بشكل مسؤول - وهي عملية تتبعها العديد من الشركات (بغض النظر عن الحجم) خارج فقاعة WP.
هناك فرصة كبيرة لمجتمع WordPress للاستفادة من Staged Rollouts ، والتي سأصل إليها بعد قليل.
هل البرامج التجريبية مشابهة للطرح التدريجي؟
يعد إعداد برنامج تجريبي لمنتج WordPress الخاص بك بداية رائعة ، ولكنه أبعد ما يكون عن الفعالية مثل Staged Rollouts ، وله غرض وديناميكية مختلفة اختلافًا جوهريًا.
ما لم يكن المكون الإضافي أو المظهر الخاص بك شائعًا للغاية ولديه مجتمع كبير ، فمن الصعب جدًا تعيين مجموعة تجريبية كافية إحصائيًا نظرًا لأن جزءًا صغيرًا فقط من المستخدمين سيكون مهتمًا بالانضمام. حتى إذا كنت تتفوق في تجنيد مجموعة مناسبة من مختبري الإصدارات التجريبية ، فعليك الاعتماد على مدى توفرهم وحسن نيتهم لاختبار المنتج ، ثم نأمل أن يبذلوا جهدًا إضافيًا للإبلاغ عن المشكلات التي يجدونها.
كم عدد الأشخاص الذين تعتقد أنهم سيرون خلال هذه العملية برمتها؟ ليس كثيرا.
اختبار بيتا هو عملية ما قبل الإنتاج حيث يتم التحكم في جهود الدعم بشكل كامل ويتوقع المختبرين وجود مشكلات في إصدارات بيتا. لذلك ، فإن توقعات المختبرين بشأن الجودة لا تمثل الشعور العام لقاعدة المستخدمين لديك.
علاوة على ذلك ، سيحذر برنامج Beta المسؤول مختبريه لتجنب استخدام إصدارات بيتا في بيئات الإنتاج ، لذا فإن الاختبار التجريبي لا يحاكي مواقع الإنتاج الحية حقًا.
كيف تدير إصدار طرح مرحلي لمكوِّن أو سمة WordPress الإضافية؟
كجزء من بحثي حول Staged Rollouts ، أتيحت لي الفرصة لمقابلة أمير هيلزر إلكترونيًا والتعلم من خبرته التي تزيد عن عامين باستخدام Staged Rollouts مع WPML و Toolset ، وهي مكونات إضافية تعمل على أكثر من 1،000،000 موقع WordPress.
إليك ما شاركه أمير حول تطبيق Staged Rollouts:
عندما يقوم موقع ويب بتثبيت أي من المكونات الإضافية الخاصة بنا ، فإننا نرسم رقمًا عشوائيًا بين 1 إلى 100 ونخزنه في قاعدة بيانات الموقع لنتذكره. تقسم هذه الطريقة بشكل أساسي مواقع الويب إلى 100 سلة بطريقة عشوائية.
عندما يكون الإصدار جاهزًا للنشر ، سيصبح متاحًا بشكل متزايد فقط لحاوية واحدة محددة. كل يوم نزيد من تعرض الإصدار إلى 5٪ إضافية من مواقع الويب في الحاوية المخصصة. ونصلح المشاكل القادمة ونصلحها ونحن نمضي قدمًا.
لتنويع البيئات باستخدام الإصدار المحدث وتجنب وجود نفس "الضحايا" للإصدار المبكر بشكل متكرر ، أكد أمير أن كل إصدار جديد يذهب إلى حاوية مختلفة من المستخدمين أولاً.
يعني هذا النهج أيضًا أن دورة الإصدار المتوسطة تستغرق حوالي شهر لتكون متاحة لكل مستخدم.
يستغرق الأمر وقتًا حتى يرى الأشخاص إصدارًا جديدًا متاحًا في WP Admin ويقوموا بتحديث نسختهم. وحتى بعد ذلك ، قد يستغرق الأمر أيامًا حتى يكتشفوا مشكلة.
مع حجم جمهورنا ، لا محالة ، كل إصدار به بعض المشكلات. هدفنا الرئيسي هو التأكد من أننا نتجنب تقديم مشكلات جديدة ، وإذا فعلنا ذلك ، فلدينا عملية موثوقة لحلها.
دورة الإصدار طويلة بالفعل ، ولكن حتى إذا كان هناك بعض الأخطاء المجنونة التي فقدناها في الاختبار ، في أسوأ السيناريوهات ، فإن 95٪ من مستخدمينا لا يدركون حتى كل الدراما ، لأنهم لم يتعرضوا للإصدار حتى تستقر.
كما أكد أمير على أهمية المزامنة مع الفريق بأكمله قبل الإصدارات ، وخاصة دعم العملاء وتطويرهم. بهذه الطريقة ، يمكن لأعضاء الفريق توفير تركيز إضافي على التذاكر التي تم تشغيلها بسبب المشكلات المتعلقة بالإصدار الجاري ، بهدف التحقق من المشكلات الصالحة وتأكيدها وإصلاحها وإصدار التصحيحات في أسرع وقت ممكن.
لدينا ثلاثة مستويات للدعم في فريقنا. سينظر المستوى 1 في المشكلة ، والتحقق من أنها في الواقع مشكلة متعلقة بإصدار المكون الإضافي عن طريق إعادة إنتاجه. عندما تبدو الحالة مرتبطة بالإصدار الجديد ، فإنها تنتقل إلى المستوى 2 ، والتي ستعمل على تصحيح المشكلة للتحقق من أنها مرتبطة بالفعل بالإصدار وتحديد الأجزاء ذات الصلة في الكود الذي أدى إلى حدوث المشكلة. إذا تم التحقق من صحته ، فسيتم إخطار المطور المسؤول عن هذا الرمز فورًا لتحديد أولويات الإصلاح.
OnTheGoSystems هي شركة كبيرة تضم ما يقرب من 100 موظف ، لذلك فمن المنطقي أنهم أتقنوا عملية الإطلاق المرحلي. ولكن ، حتى بصفتك مطور منتج واحد مع مستوى دعم واحد (أنت وأنت نفسك) ، يمكن لرؤى أمير أن تعلمنا أنه من الضروري تخصيص موارد مخصصة للإصدارات. من الممارسات الجيدة إعطاء الأولوية لتذاكر الدعم التي "تشم رائحتها" حتى ترتبط بإصدارك الجديد وتقليل التعرض للمشكلات الجديدة قدر الإمكان.
لماذا لا توجد (تقريبًا) مكونات إضافية أو سمات تدعم الطرح المرحلي؟
استعدادًا لكتابة هذا المقال ، حاولت أن أطلب من المجتمع معرفة من يستخدم العروض التدريجية من أجل الحصول على تعليقات حول تجربتهم ، وما تعلموه ، وما إلى ذلك.
مما لا يثير الدهشة ، أنني وجدت شركتين فقط من WordPress في شبكتي قامت بإعداد Staged Rollouts كجزء من دورة الإصدار الخاصة بهم. لم يكن العديد من المطورين يعرفون هذا المفهوم ، والبقية لا يستخدمونه لأن حل التوزيع الخاص بهم لا يدعمه (أو ربما فكروا في تطويره وليس لديهم الوقت).
معظم مطوري المكونات الإضافية والموضوعات الذين لا يبيعون من خلال Freemius يبيعون من موقع الويب الخاص بهم عبر EDD أو WooCommerce ، وكلاهما لا يدعم Staged Rollouts. أولئك الذين يبيعون من خلال أسواق مثل CodeCanyon و ThemeForest أيضًا ليس لديهم حل جاهز ، وعلى الأرجح لن يحصلوا عليه أبدًا.
حتى المطورين الذين هم على دراية بالمفهوم ليس لديهم خيار سوى تطوير آليتهم الخاصة لدعم عمليات الطرح المرحلي. عادةً ما يكون من الصعب جدًا تحديد أولويات تطوير البنية التحتية داخل شركة منتج.
اشترك واحصل على نسخة مجانية من موقعنا
WordPress البرنامج المساعد كتاب الأعمال
بالضبط كيفية إنشاء عمل إضافي لبرنامج WordPress مزدهر في اقتصاد الاشتراك.
شارك مع صديق
أدخل عنوان البريد الإلكتروني لصديقك. سنرسل لهم هذا الكتاب بالبريد الإلكتروني فقط ، شرف الكشافة.
شكرا لك للمشاركة
رائع - تم إرسال نسخة من "The WordPress Plugin Business Book" إلى . هل تريد مساعدتنا في نشر الكلمة أكثر؟ استمر وشارك الكتاب مع أصدقائك وزملائك.
شكرا على الإشتراك!
- لقد أرسلنا نسختك من "The WordPress Plugin Business Book" إلى .
هل لديك خطأ مطبعي في بريدك الإلكتروني؟ انقر هنا لتعديل عنوان البريد الإلكتروني وإرساله مرة أخرى.
كيف تمنحك الطروحات المرحلية ميزة تجارية؟
نظرًا لأن لا أحد تقريبًا يستفيد من النشرات المرحلية في الوقت الحالي ، إذا بدأت في استخدام Staged Rollouts وتسويقها بشكل صحيح على موقع الويب الخاص بك لإعلام الزائرين بأن لديك دورات إصدار مسؤولة ، فهذا يمنحك بالتأكيد ميزة تنافسية ويزيد الثقة في منتجك /ماركة!
إذا قمت بتحليل السوق من منظور المطور ، فستلاحظ أن العديد من المطورين يتابعون عن كثب منافسيهم وعادةً ما يحددون أسعارهم ضمن النطاق السعري للسوق في مجالهم الرأسي ، مما يؤدي إلى منتجات WordPress المنافسة التي تقدم ميزات مماثلة في نفس النطاق السعري.
من وجهة نظر المشتري ، هذا يعني أنه غالبًا ما يكون هناك إهمال حول المنتج الذي يجب شراؤه لأن لديهم جميعًا ميزات وأسعارًا قابلة للمقارنة. ولكن ، عندما تقوم بتقييم العديد من المكونات الإضافية التي تكلف نفس التكلفة ، وتتمتع بنفس الميزات ، سواء أكانت تعطيها أم تأخذها ، ألن تميل إلى استخدام المنتج الذي يقدم العروض التدريجية مع العلم أن إصدارات الإنتاج الخاصة به يجب أن تكون أكثر استقرارًا من المنافسين؟
تزيد عمليات الطرح على مراحل من الثقة في منتجك وعملك. إنها ميزة يمكنك الاستفادة منها قبل أن تصبح العروض التقديمية المرحلية ممارسة قياسية (وهو ما أتمنى حقًا أن يفعلوه).
يدعم Freemius الآن طرح مرحلي للإضافات والسمات المدفوعة
نحن متحمسون للريادة في Staged Rollouts في إضافات ووردبريس المتميزة والنظام البيئي للقوالب. يمكن لشركائنا البائعين الآن إصدار التحديثات بأمان وثقة وموثوقية ، مع الحد الأدنى من ردود الفعل السلبية لمستخدميهم أو موارد الدعم / التطوير.
نحن نعلم كيف يمكن أن تكون الإصدارات الرئيسية صعبة ومرهقة للأعصاب ، خاصة وأن هناك دائمًا خطر محتمل يتمثل في التأثير السلبي على علامتك التجارية بعد إصدار "Clusterbug".
من خلال تطبيق Staged Rollouts ، هناك شبكة أمان لاستدامة العلامة التجارية لشركائنا وقابلية الدفاع عنها ، وتخفيف الضغط غير الضروري المرتبط بالإصدارات إلى قاعدة مستخدمين كبيرة.
يسير هذا جنبًا إلى جنب باعتباره منفعة لعملاء شركائنا. عندما يشتري المستخدمون المنتجات المباعة من خلال Freemius ، يمكنهم الآن أن يثقوا في أنهم يختارون حلًا مدعومًا من Staged Rollouts ويمكنهم توقع إصدارات أكثر استقرارًا من المكونات الإضافية والسمات المتميزة باستخدام الآلية.
إذا كنت تبيع مع Freemius ، فإليك كيفية استخدام آلية Staged Rollouts الخاصة بنا بشكل صحيح.
كيف نفذ Freemius عمليات الطرح على مراحل؟
كل موقع ويب ينشط ترخيصًا لإلغاء تأمين مكون إضافي أو سمة مميزة يحصل على سجل في قاعدة البيانات الخاصة بنا. أول شيء قمنا به هو تقديم خاصية last_served_update_version الجديدة لتخزين أحدث إصدار من المنتج الذي تم توفيره لموقع ويب.
بعد ذلك ، قمنا بإثراء الجدول المسؤول عن تخزين بيانات الإصدار بخاصيتين جديدتين: limit ، uniques .
عندما يقوم مطور بوضع علامة على إصدار على أنه تم إصداره ، سيُطلب منه باستخدام مربع الحوار التالي ، مما يسمح له بإعداد النسبة المئوية (أو عدد) مواقع الويب التي لديها ترخيص نشط ويريدون طرح الإصدار المدفوع من أجله:
إذا قاموا بتعيين إصدار محدود ، فسيقوم النظام بحساب إجمالي مواقع الويب النشطة بترخيص نشط ثم تعيين خاصية limit الجديد للإصدار وفقًا لذلك.
أخيرًا ، قمنا بتحديث نقطة نهاية API التي استدعتها مواقع الويب للتحقق مما إذا كان هناك إصدار جديد وقدمنا المنطق التالي (في رمز زائف):
latest_version = load latest version of product X
If (website is on latest_version)
return “no new version”
If (last_served_update_version of website same as latest_version)
return “no new version”
If (latest_version is limited)
If (latest_version is limited AND uniques >= limit)
return “no new version”
previous_version = load the previous version of product X
If (previous_version is limited too AND uniques <= previous_version.uniques)
If (website not using previous_version AND
last_served_update_version different from previous_version)
return “no new version”
else If (random({true, false}) )
return “no new version”
Set last_served_update_version of website to latest_version
Increment uniques by 1
return latest_version
تضمن هذه الخوارزمية ما يلي:
- يتم تحديد التعرض للإصدار وفقًا للنسبة المئوية المحددة للطرح.
- إذا كان الإصدار السابق لا يزال على مراحل ، أي أنه لم يتم عرضه مطلقًا على قاعدة التثبيت بأكملها ، فستتعرض مواقع الويب التي تلقت الإصدار المرحلي السابق إلى أحدث إصدار مرحلي أولاً.
على عكس بنية الطرح المرحلي الخاصة بـ WPML والتي تضمن أن كل إصدار سينتقل إلى مجموعة فرعية مختلفة من قاعدة التثبيت الخاصة به باستخدام الصناديق المنطقية ، يعتمد تنفيذنا على العشوائية. لذلك ، قد يحصل موقع ويب على إصدارين في مرحلة مبكرة في دورتين متتاليتين من الإصدارات. ومع ذلك ، فإن فائدة هذا النهج هي أننا كنا قادرين على شحن Staged Rollouts لجميع عملاء شركائنا دون الحاجة إلى دفع تحديث SDK ، والذي قد يستغرق عدة أشهر ، أو حتى سنوات ، لنشره لجميع العملاء.
لماذا تعتبر العروض التدريجية ضرورية لمستقبل WordPress؟
عندما سألت أمير عن الدافع الذي دفعهم إلى تطوير التدفقات المرحلية لدورات إصدار WPML ، هذا ما قاله لي:
قبل 3 سنوات ، في WordCamp Europe ، قضيت وقتًا في الدردشة مع عملاء WPML لجمع جميع أنواع الملاحظات حول تجربتهم الإجمالية. كان الإحباط الأول الذي وجدته هو أن عملائنا كانوا يخشون تحديث المكون الإضافي لأنه يمكن أن يكسر موقعهم بشكل غير متوقع.
أمير هلزر
مؤسس OnTheGoSystems (WPML ، Toolset)
أنا مرتبط بذلك تمامًا.
سياستنا الداخلية في Freemius عندما يتعلق الأمر بتحديث المكونات الإضافية والقوالب هي ... ببساطة لا تفعل ذلك! مع استثناءين: إذا كانت هناك مشكلة أمنية معروفة أو ميزة متوفرة في إصدار أحدث نحتاجه لموقعنا.
تمت كتابة سياسة التحديثات الخاصة بنا "بالدم" بعد عدة حوادث من التحديثات التي حدثت بشكل خاطئ وتسببت في حدوث صداع غير متوقع وإضاعة للوقت ، مما أدى إلى مقاطعة عملياتنا وجداولنا الزمنية. ونعم ، كان بإمكاننا تجنب بعض الضغوط من خلال بيئة التدريج ، لكن هذا لم يكن ليوفر لنا الوقت والإزعاج إذا كنا لا نزال نرغب في متابعة التحديث للإنتاج.
لقد تطور WordPress قليلاً منذ ذلك الحين ، والآن لدينا إلغاء تنشيط تلقائي عند فشل المكونات الإضافية. ومع ذلك ، هذا لا ينطبق على السمات وإلغاء تنشيط مكون إضافي مهم للمهام لموقعنا على الويب لا يزال يمثل مشكلة كبيرة.
خلاصة القول هي أنه إذا كنت ، بصفتي مطورًا للمكونات الإضافية والرئيس التنفيذي لشركة تساعد الآلاف من مطوري المكونات الإضافية والقوالب على تنمية أعمالهم ، أشعر بالقلق إزاء كسر موقعنا في كل مرة نقوم فيها بتحديث المكونات الإضافية أو السمات على موقعنا ، فهذا يعني بالتأكيد لا يثق معظم المستخدمين في تحديث البرامج في مساحتنا.
يؤدي عدم وجود عروض مرحلية إلى عودة النظام البيئي الخاص بـ WP بالكامل إلى الوراء ويعطي الحلول المنافسة القائمة على SaaS ميزة كبيرة. لا يحتاج مستخدمو WiX و Shopify إلى التفكير في التحديثات على الإطلاق! التحديثات تحدث فقط لهم في الخلفية ، ودائمًا ما تكون برامجهم محدثة وآمنة وحكيمة.
يؤدي عدم وجود عمليات طرح مرحلية إلى عودة نظام WP البيئي بالكامل مرة أخرى ويمنح الحلول المستندة إلى SaaS ميزة كبيرة. لا يحتاج مستخدمو WiX و Shopify إلى التفكير في تحديثات البرامج - فهي تحدث فقط في الخلفية
إذا شاهدت حالة الكلمة الأسبوع الماضي ، فإن المؤسس المشارك لـ WordPress ، Matt Mullenweg ، يدرك بوضوح أهمية البرامج المحدثة. إليك رؤية Matt لتحديثات WP:
... مما يتيح لك الاشتراك في التحديثات التلقائية لـ Core. هذه هي الخطوة الأولى نحو هدفنا الذي يسمح لـ WordPress الخاص بك بالحفاظ على نفسه بشكل أساسي ، عندما يمكنك تعيينه ونسيانه ، وسيحصل على تحديثات تلقائية في الخلفية وخالية من المتاعب لجميع المكونات الإضافية والسمات والأساسية.
الطريقة الوحيدة التي يمكنني بها تخيل أن WordPress أصبح "مجموعة ونسيان" هي ما إذا كانت تحديثات البرامج يمكن أن تكون أكثر موثوقية وموثوقية ، وهذا لا يمكن أن يحدث إلا مع Staged Rollouts.
WordPress.org: إليك كيف يمكنك تقديم طرح مرحلي للمكوِّن الإضافي ومستودع السمات
على غرار التنفيذ الخاص بنا ، يجب إضافة خيارين meta جديدين إلى كل مكون إضافي وإصدار سمة في قاعدة بيانات WordPress.org: uniques limit
يمكن الكشف عن تحرير خيار meta limit في طريقة العرض المتقدمة للمالك المسجل (وربما للمشتركين الآخرين):
سيكون لدى المطور طريقة للتحكم في تعرض كل إصدار ، بالإضافة إلى القدرة على تعيين حد للإصدار التالي.
نظرًا لأن WordPress.org لا يخزن البيانات المنظمة لكل موقع ويب يتلقى تحديثات من WordPress.org ، بدلاً من تخزين أحدث إصدار "يراه" موقع ويب في قاعدة بيانات WordPress.org ، يمكن تفويض تخزين البيانات إلى مواقع الويب . هذا يعني أن 'update_plugins' عابر والبيانات المرسلة إلى WordPress.org API عند البحث عن التحديثات ستحتاج إلى إثرائها باستخدام last_served_update_version .
أخيرًا ، يمكن إثراء نقاط نهاية API لتحديثات WordPress.org بنفس المنطق الذي استخدمناه لتنفيذ Freemius Staged Rollouts. فقط بدلاً من الاعتماد على last_served_update_version من قاعدة بيانات wp.org ، ستعتمد الآلية على القيمة المرسلة من موقع الويب حسب النواة.
سهل ، أليس كذلك؟
هو توظيف 
دعنا نعيد ثقة المستخدمين بالضغط على زر التحديث
نريد جميعًا أن نرى WordPress ينجح وينمو باستمرار بشكل أكبر وأفضل!
مع وجود العديد من الموارد في Gutenberg ، من الواضح أن قيادة WordPress تقر بأن علينا جعل طريقة النظام الأساسي أكثر سهولة بالنسبة لمتوسط Joe غير التقني. الشيء هو أنه طالما أنه لا يمكن الوثوق بتحديثات البرامج ، حتى مع Gutenberg وجميع منشئي الصفحات المذهلين المتاحين لدينا ، فسوف يهرب شخص غير فني إلى Wix في أول تحديث مكسور ، ولا يمكنني إلقاء اللوم هم.
أناشد مؤسس EDD ، بيبين ويليامسون ، الرئيس التنفيذي لشركة WooCommerce ، بول مايورانا ، وفريق WordPress.org: لدينا فرصة لجعل النظام البيئي للمكوِّن الإضافي والموضوع أكثر استقرارًا لمجتمع WordPress الأكبر. دعنا نمكن المستخدمين من الحفاظ على أمان برامجهم وتحديثها بأقل قدر من الخوف والإحباط. على الرغم من أنها قد لا تبدو ذات أولوية عالية على المدى القصير ، إلا أنني متأكد من أننا سنستفيد منها جميعًا على المدى الطويل.