خمس تقنيات تم اختبارها في المعركة لا يستخدمها مطور واجهة برمجة تطبيقات WordPress

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

لسوء الحظ ، أنت تتعامل مع عميل أكثر تطلبًا إلى حد ما وقد لاحظوا العيوب التالية:

• على الرغم من أن الأداة ، مثل باقي أجزاء الموقع ، تتميز بخط sans-serif ، إلا أنها ليست الخيار الصحيح تمامًا. الأداة تستخدم Helvetica بدلاً من الخط المخصص الذي قمت بتثبيته.
• يؤدي نموذج الاشتراك في الأداة إلى بدء تحميل صفحة جديدة ، والتي يمكن أن تكون معطلة إذا تم وضعها في منتصف المقالة.
• يبدو أن الأداة تستغرق وقتًا إضافيًا ليتم تحميلها بعد باقي الصفحة ، والتي تبدو مزعجة ورخيصة.
• يرغب العميل في أن يتم تمييز المشتركين ببيانات وصفية بناءً على المنشور الذي اشتركوا منه ، ولا تقدم الأداة أي شيء يشبه هذه الوظيفة عن بُعد.
• يجد العميل أنه من المزعج أنه سيتعين عليه الآن إدارة لوحتين (wp-admin ومنطقة الإدارة لخدمة البريد الإلكتروني).

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

على مدار العقد الماضي ، استخدمت WordPress كمنصة لاستهلاك واجهة برمجة التطبيقات مقابل 50 واجهة برمجة تطبيقات مختلفة على الأرجح. بعض واجهات برمجة التطبيقات الأكثر شيوعًا هي MailChimp و Google Analytics و Google Maps و CloudFlare و Bitbucket. ولكن ماذا لو كنت بحاجة إلى فعل المزيد ، ماذا لو كنت بحاجة إلى حل مخصص؟

كيفية تطوير عميل WordPress API

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

• عائلة وظائف WordPress HTTP
• جسون
• راحة

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

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

ملاحظة: إذا كنت بحاجة إلى دورة تدريبية سريعة لتجديد المعلومات ، يمكنك مراجعة دليل WordPress REST API الخاص بنا.

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

العابرين: متى تمسكهم ، ومتى تطويهم

في الفقرة الافتتاحية الخاصة بي ، لاحظت أن العميل وجد أنه من المزعج أن يمتد بين منطقتين إداريتين: wp-admin ولوحة القيادة لخدمة البريد الإلكتروني الخاصة به. من الطرق الجيدة لحل هذه المشكلة تزويدهم بأداة لوحة معلومات في wp-admin ، لعرض ملخص لنشاط المشتركين الأخير.

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

1. احصل على البيانات من API البعيد.
2. قم بتخزينه باستخدام set_transient() مع وقت انتهاء صلاحية من اختيارك بناءً على حكمك الخاص حول الأداء وحدود الأسعار وهامش الخطأ في عرض البيانات القديمة في هذا التطبيق المعين.
3. تابع في منطق عملك - معالجة البيانات ، وإرجاع قيمة ، مهما كانت الحالة.
4. عندما تحتاج إلى البيانات مرة أخرى ، مثل تحميل الصفحة التالية ، تحقق منها في ذاكرة التخزين المؤقت المؤقتة باستخدام get_transient() قبل أن تستنتج أنك بحاجة إلى الحصول عليها من واجهة برمجة التطبيقات.

أنا أعتبر هذا أساسًا مفيدًا وقابل للتطبيق ، ولكن يمكنك أن تأخذ خطوة إلى الأمام إذا فكرت للحظة في أفعال REST. من بين الطرق الخمس الأكثر شيوعًا (GET ، POST ، PATCH ، PUT ، DELETE) ، تنتمي واحدة فقط منها إلى ذاكرة التخزين المؤقت المؤقتة. يمكنك تخمين أي واحد؟ إنه GET. في الإضافات الخاصة بي ، لدي دائمًا فئة PHP مخصصة لاستخراج المكالمات إلى واجهة برمجة التطبيقات البعيدة المعنية ، والحجة عند إنشاء هذه الفئة هي طريقة HTTP. إذا لم تكن مكالمة GET ، فلن أستدعي أي طبقة تخزين مؤقت على الإطلاق.

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

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

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

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

أحيانًا لا يكون العابرون جيدين بما فيه الكفاية

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

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

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

حتى لو كنت ذكيًا بما يكفي لمساحة الأسماء لجميع مفاتيحك المؤقتة بحيث يكون لديك بعض الأمل في تحديد كل منها من أجل delete_transient() ، ربما لا يزال السيناريو الأفضل يتضمن SQL الأولية ، والتي أحاول دائمًا تجنبها في WordPress:

 <?php // Purge all the transients associated with our plugin. function purge() { global $wpdb; $prefix = esc_sql( $this -> get_transient_prefix() ); $options = $wpdb -> options; $t = esc_sql( "_transient_timeout_$prefix%" ); $sql = $wpdb -> prepare ( " SELECT option_name FROM $options WHERE option_name LIKE '%s' ", $t ); $transients = $wpdb -> get_col( $sql ); // For each transient... foreach( $transients as $transient ) { // Strip away the WordPress prefix in order to arrive at the transient key. $key = str_replace( '_transient_timeout_', '', $transient ); // Now that we have the key, use WordPress core to the delete the transient. delete_transient( $key ); } } ?>

ليست مريحة وغير فعالة. بدلاً من ذلك ، يستدعي هذا الموقف التخزين المؤقت للكائن لأن التخزين المؤقت للكائن يمنحنا طريقة مناسبة لتجميع القيم المخزنة مؤقتًا معًا . بهذه الطريقة ، عندما تحتاج إلى إفراغ جميع القيم المخزنة مؤقتًا المتعلقة بالمكوِّن الإضافي الخاص بك ، فهي عبارة عن استدعاء بسيط من سطر واحد إلى wp_cache_delete( $key, $group ) .

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

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

يمكن لواجهة برمجة التطبيقات عن بُعد المساعدة في إعلام التسلسل الهرمي لفئة PHP

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

• https://api.example-email-service.com/v1/subscribers.json
• https://api.example-email-service.com/v1/lists.json
• https://api.example-email-service.com/v1/campaigns.json

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

• class.collection.php ، فئة مجردة
• يمتد class.subscribers.php إلى فئة الملخص ، Collection .
• يوسع class.lists.php فئة abstract ، Collection .
• يمتد class.campaigns.php فئة abstract ، Collection .

قد تتخذ فئة الملخصات ، كوسيطة وحيدة لها ، مصفوفة من معاملات الاستعلام: أشياء مثل ترقيم الصفحات ، وعمود الفرز ، وترتيب الفرز ، وعوامل تصفية البحث. سيكون لها طرق للمهام الشائعة مثل استدعاء واجهة برمجة التطبيقات البعيدة ، ومعالجة الأخطاء ، وربما تحويل النتائج إلى قائمة HTML <select> أو jQueryUI AutoSuggest. قد تكون الفئات التي تنشئ فئة الملخصات قصيرة جدًا ، وربما تفعل أكثر من مجرد تحديد السلسلة لاستخدامها في عنوان URL لنقطة نهاية واجهة برمجة التطبيقات *.json .

وبالمثل ، ما الذي تشترك فيه نقاط النهاية التالية؟

• https://api.example-email-service.com/v1/subscribers/104abyh4.json
• https://api.example-email-service.com/v1/lists/837dy1h2.json
• https://api.example-email-service.com/v1/campaigns/9i8udr43.json

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

• class.item.php ، فئة مجردة
• يوسع class.subscriber.php فئة الملخص ، Item .
• يوسع class.list.php فئة الملخص ، Item .
• يوسع class.campaign.php فئة الملخص ، Item .

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

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

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

حالة الاستخدام المثالية لـ WP_Error

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

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

على سبيل المثال ، ربما أجرينا اتصالاً بنقطة النهاية /lists.json ، لكن هذا الحساب المعين لا يحتوي حتى الآن على أي قوائم معدة. سيعيد هذا استجابة HTTP صالحة ، ولكن مع رمز الحالة 400. في حين أن هذا ليس خطأ فادحًا في حد ذاته ، من منظور بعض التعليمات البرمجية للواجهة الأمامية التي تريد تحويل استدعاء واجهة برمجة التطبيقات هذا إلى قائمة منسدلة ، فقد يكون 400 وكذلك يكون WSOD! لذلك ، أجد أنه من المفيد إجراء بعض التحليل الإضافي لنتيجة wp_remote_request() ، مما قد يؤدي إلى إرجاع WP_Error بعد كل شيء:

 <?php function call() { $response = wp_remote_request( $this -> url, $this -> args ); $code = wp_remote_retrieve_response_code( $response ); $first_digit = $code[0]; $good_responses = array( 2, 3 ); if( ! in_array( $first_digit, $good_responses ) { $body = wp_remote_retrieve_body( $response ); $out = new WP_Error( $code, $body ); } else { $out = $response; } return $out; } ?>

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

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

قوة التصحيح الجميلة لـ ob_get_clean()

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

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

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

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

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

 <?php function debug( $bug ) { ob_start(); var_dump( $bug ); $out = ob_get_clean(); error_log( $out ); } ?>

هذا يرقى إلى var_dump() 'إدخال قيمة عربات التي تجرها الدواب بأكملها في إدخال واحد في ملف سجل الأخطاء.

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

ليس بالضبط Clickbait ، لكنه سيفعل

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

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