ห้าเทคนิคการทดสอบการต่อสู้ที่นักพัฒนา WordPress API ของคุณไม่ได้ใช้

หนึ่งในวิธีที่ดีที่สุดในการยกระดับสถานะของคุณในฐานะนักพัฒนา WordPress อย่างน้อยก็ในสายตาลูกค้าของคุณ คือการมีทักษะในการใช้ API นี่เป็นสถานการณ์ทั่วไปสำหรับการนำ WordPress API ไปใช้: ลูกค้าของคุณขอให้คุณเพิ่มวิดเจ็ตในเว็บไซต์ของตน เช่น วิดเจ็ตการสมัครรับข้อมูลอีเมล คุณรับโค้ดจากบริการอีเมลของบริษัทอื่น ซึ่งอาจเป็นแท็กสคริปต์หรือ iframe ให้วางลงในเพจและตอบกลับลูกค้าของคุณว่า "รับทราบ!"

ขออภัย คุณกำลังติดต่อกับลูกค้าที่มีความต้องการค่อนข้างสูง และพวกเขาสังเกตเห็นความไม่สมบูรณ์ดังต่อไปนี้:

• แม้ว่าวิดเจ็ตจะเหมือนกับส่วนอื่นๆ ของไซต์ที่มีฟอนต์ sans-serif แต่ก็ไม่ใช่ฟอนต์ที่ถูกต้อง วิดเจ็ตนี้ใช้ Helvetica แทนฟอนต์แบบกำหนดเองที่คุณได้ติดตั้งไว้
• แบบฟอร์มการสมัครของวิดเจ็ตจะทริกเกอร์การโหลดหน้าใหม่ ซึ่งอาจทำให้หยุดชะงักได้หากวางไว้ครึ่งทางของบทความ
• วิดเจ็ตนี้ดูเหมือนจะใช้เวลาโหลดนานขึ้นหลังจากอ่านส่วนที่เหลือของหน้า ซึ่งรู้สึกว่ามีเสียงดังและราคาถูก
• ลูกค้าต้องการให้สมาชิกถูกแท็กด้วยข้อมูลเมตาตามโพสต์ที่พวกเขาสมัครรับข้อมูล และวิดเจ็ตไม่ได้เสนอสิ่งที่คล้ายกับฟังก์ชันการทำงานนี้จากระยะไกล
• ลูกค้าพบว่ามันน่ารำคาญที่พวกเขาจะต้องจัดการสองแดชบอร์ด (wp-admin และพื้นที่ผู้ดูแลระบบสำหรับบริการอีเมล)

ณ จุดนี้ หนึ่งในสองสิ่งอาจเกิดขึ้นอย่างสมเหตุสมผล คุณสามารถประกาศรายการเหล่านี้ว่า "น่ามี" และสร้างความมั่นใจให้กับลูกค้าของคุณเกี่ยวกับข้อดีของโซลูชัน 80/20 หรือคุณสามารถดำเนินการตามคำขอเหล่านั้นได้ จากประสบการณ์ส่วนตัวของฉัน ฉันพบว่าการส่งมอบตามคำขอดังกล่าว ซึ่งก็คือการแสดงให้เห็นถึงความเชี่ยวชาญในบริการของบุคคลที่สาม เป็นวิธีที่น่าเชื่อถือในการโน้มน้าวให้ลูกค้าเชื่อว่าคุณเป็นวิซาร์ด WordPress ในรูปแบบต่างๆ นอกจากนี้ มันมักจะสนุกที่จะทำ

กว่าทศวรรษที่ผ่านมา ฉันได้ใช้ WordPress เป็นแพลตฟอร์มสำหรับการใช้ API กับ API ที่แตกต่างกันกว่า 50 รายการ API ทั่วไปบางส่วน ได้แก่ MailChimp, Google Analytics, Google Maps, CloudFlare และ Bitbucket แต่ถ้าคุณต้องการทำมากกว่านี้ ถ้าคุณต้องการโซลูชันที่กำหนดเองล่ะ

วิธีพัฒนาไคลเอนต์ WordPress API

ในบทความนี้ ฉันจะพัฒนาเทียบกับ API ของ "บริการอีเมล" ทั่วไป โดยพยายามทำให้ดีที่สุดเพื่อให้สิ่งต่าง ๆ ไม่เชื่อเรื่องพระเจ้ามากที่สุด อย่างไรก็ตาม ฉันคิดว่ามันสมเหตุสมผลที่จะถือว่าเรากำลังติดต่อกับ JSON REST API ต่อไปนี้เป็นหัวข้อพื้นฐานที่อาจช่วยให้คุณเพลิดเพลินกับประเด็นทางเทคนิคในบทความนี้:

• ฟังก์ชันตระกูล WordPress HTTP
• JSON
• พักผ่อน

หากคุณพบว่าตัวเองคุ้นเคยกับหัวข้อเหล่านี้เพียงเล็กน้อยและสนใจที่จะเจาะลึกลงไป ให้หยุดตอนนี้และดาวน์โหลดแอปพลิเคชั่นบุรุษไปรษณีย์ที่ยอดเยี่ยม ช่วยให้คุณสื่อสารกับ API ได้โดยไม่ต้องเขียนโค้ด

อย่างไรก็ตาม หากคุณไม่คุ้นเคยกับสิ่งเหล่านั้นเลย ให้อ่านต่อ ผู้ชมทางเทคนิคที่มีประสบการณ์ WordPress ในระดับหนึ่งจะได้รับประโยชน์สูงสุดจากบทความนี้ แต่ฉันจะอธิบาย คุณค่า ของแต่ละเทคนิคด้วยวิธีที่ไม่ค่อยใช้เทคนิค ผู้อ่านที่ไม่ใช่ด้านเทคนิคจะปล่อยให้บทความนี้สามารถประเมิน ROI ของแต่ละจุดก่อนที่จะสนับสนุนและตัดสินคุณภาพของการดำเนินการเมื่อจัดส่ง

หมายเหตุ: ในกรณีที่คุณต้องการหลักสูตรทบทวนอย่างรวดเร็ว คุณสามารถดูคู่มือ WordPress REST API ของเราได้

เมื่อไม่มีคำนำ ให้ฉันแบ่งปันเทคนิคต่างๆ ที่ฉันรู้สึกซาบซึ้งกับ API โครงการและทีมงานเกือบทั้งหมดที่ฉันทำงานด้วย

ชั่วขณะ: เมื่อใดควรถือ เมื่อใดควรพับ

ในย่อหน้าเริ่มต้นของฉัน ฉันสังเกตว่าลูกค้าพบว่ามันน่ารำคาญที่จะข้ามสองส่วนผู้ดูแลระบบ: wp-admin และแดชบอร์ดสำหรับบริการอีเมลของพวกเขา วิธีที่ดีในการแก้ปัญหาคือการจัดหาวิดเจ็ตแดชบอร์ดใน wp-admin เพื่อแสดงสรุปกิจกรรมสมาชิกล่าสุด

แต่แล้วอีกครั้ง การดำเนินการนี้อาจต้องใช้คำขอ HTTP หลายรายการไปยัง API ระยะไกล (API ที่บริการอีเมลจัดเตรียมให้) ส่งผลให้มีการโหลดหน้าเว็บนาน วิธีแก้ไขปัญหาด้านประสิทธิภาพนี้คือการจัดเก็บการเรียก API เป็นการชั่วคราว บทความ Codex นี้ให้คำอธิบายที่ยอดเยี่ยมที่คุณควรอ่าน แต่ฉันจะสรุปดังนี้:

1. รับข้อมูลจาก API ระยะไกล
2. จัดเก็บโดยใช้ set_transient() โดยมีเวลาหมดอายุที่คุณเลือกตามการพิจารณาของคุณเองเกี่ยวกับประสิทธิภาพ การจำกัดอัตรา และข้อผิดพลาดในการแสดงข้อมูลที่ล้าสมัยในแอปพลิเคชันนี้โดยเฉพาะ
3. ดำเนินการตามตรรกะทางธุรกิจของคุณ—ประมวลผลข้อมูล คืนค่า ไม่ว่าในกรณีใด
4. เมื่อคุณต้องการข้อมูลอีกครั้ง เช่น ในการโหลดหน้าถัดไป ให้ตรวจสอบในแคชชั่วคราวโดยใช้ get_transient() ก่อนสรุปว่าคุณจำเป็นต้องรับข้อมูลจาก API

ฉันคิดว่าสิ่งนี้เป็นรากฐานที่เป็นประโยชน์และเป็นไปได้ แต่คุณสามารถก้าวไปอีกขั้นได้หากคุณคิดสักครู่เกี่ยวกับกริยา REST จากห้าวิธีที่พบบ่อยที่สุด (GET, POST, PATCH, PUT, DELETE) มีเพียงหนึ่งวิธีเท่านั้นที่อยู่ในแคชชั่วคราวของคุณ คุณเดาได้ไหมว่าอันไหน? มันคือ GET ในปลั๊กอินของฉัน ฉันมักจะมีคลาส PHP ที่ทุ่มเทให้กับการแยกการโทรไปยัง API ระยะไกลที่เป็นปัญหา และการโต้แย้งเมื่อสร้างอินสแตนซ์ของคลาสนั้นคือเมธอด HTTP หากไม่ใช่การโทร GET ฉันจะไม่เรียกใช้แคชเลเยอร์เลย

นอกจากนี้ หากไม่ใช่การโทร GET แสดงว่าฉันกำลังดำเนินการบางอย่างเพื่อแก้ไขข้อมูลระยะไกลในทางใดทางหนึ่ง อาจเป็นโดยการเพิ่ม แก้ไข หรือลบสมาชิกอีเมล นี่อาจเป็นเวลาที่เหมาะสมในการทำให้แคชที่มีอยู่เป็นโมฆะสำหรับทรัพยากรนั้น ผ่าน delete_transient()

หากต้องการย้อนกลับไปที่ตัวอย่าง API การสมัครรับอีเมลของ WordPress มีวิธีปฏิบัติดังนี้

• วิดเจ็ตแดชบอร์ดสำหรับแสดงสมาชิกล่าสุดกำลังจะเรียกปลายทาง API สำหรับ /subscribers ผ่านคำขอ GET เนื่องจากเป็นคำขอ GET จึงถูกเก็บไว้ในแคชชั่วคราวของฉัน
• วิดเจ็ตแถบด้านข้างสำหรับสมัครรับรายชื่ออีเมลจะเรียกปลายทาง API สำหรับ /subscribers ผ่านคำขอ POST เนื่องจากเป็นคำขอ POST ไม่เพียงแต่จะหลีกเลี่ยงแคชชั่วคราวเท่านั้น แต่ยังกระตุ้นให้ฉันลบส่วนที่เกี่ยวข้องของแคชชั่วคราวของฉัน เพื่อให้วิดเจ็ตแดชบอร์ดสะท้อนถึงผู้สมัครสมาชิกใหม่นี้
• เมื่อตั้งชื่อ transients ฉันมักจะจัดระเบียบมันโดยการตั้งชื่อตามตัวอักษรตาม URL API ระยะไกลที่ฉันกำลังเรียก นี่เป็นวิธีที่สะดวกในการระบุช่วงเวลาที่ถูกต้องที่จะลบ หากเป็นจุดปลายทางที่มีอาร์กิวเมนต์ ฉันจะเชื่อมข้อมูลเหล่านั้นเป็นสตริงและเพิ่มลงในชื่อชั่วคราวด้วย

ในฐานะลูกค้าหรือผู้มีส่วนได้ส่วนเสียด้านเทคนิคอื่น ๆ คุณควรร้องขอการแคชชั่วคราวโดยเฉพาะ หรืออย่างน้อยที่สุดให้มีการอภิปรายเมื่อใดก็ตามที่แอปพลิเคชันดึงข้อมูลจากบริการระยะไกล คุณควรทำความคุ้นเคยกับปลั๊กอิน Query Monitor ที่ยอดเยี่ยม เพื่อดูว่าทรานเซียนท์ทำงานอย่างไร มันจะให้อินเทอร์เฟซแก่คุณสำหรับการเรียกดูว่าข้อมูลใดที่ถูกซ่อนไว้ชั่วคราว บ่อยเพียงใด และนานเท่าใด

บางครั้งความชั่วครู่ก็ยังดีไม่พอ

บริการโฮสติ้ง WordPress ระดับพรีเมียมบางอย่างไม่อนุญาตให้คุณใช้ชั่วคราวในการผลิต พวกเขามีโค้ดที่ทำงานอยู่ บางทีอยู่ในรูปแบบของปลั๊กอิน MU หรือสคริปต์อื่น ๆ ที่จะสกัดกั้นความพยายามของคุณในการใช้ API ชั่วคราวและจัดเก็บข้อมูลนั้นผ่านแคชวัตถุแทน WP-Engine ในการกำหนดค่าทั่วไปเป็นตัวอย่างที่สำคัญของสิ่งนี้

หากคุณเพียงแค่จัดเก็บและเรียกข้อมูล จริงๆ แล้วคุณไม่จำเป็นต้องสนใจเรื่องนี้ และอาจไม่เคยสังเกตด้วยซ้ำว่ากำลังเกิดขึ้น ฟังก์ชันตระกูล *_transient() ทั้งหมดจะให้ผลลัพธ์ที่เหมือนกันกับคุณ เพียงกรองเพื่อใช้แคชของวัตถุแทนแคชชั่วคราว ที่ซึ่งคุณอาจพบปัญหาคือเมื่อพยายามลบชั่วคราว นี่คือเหตุผล

หากการรวม API ของคุณซับซ้อนพอที่จะใช้หน้าการตั้งค่าของตัวเอง คุณอาจต้องการรวม UI เพื่ออนุญาตให้ผู้ดูแลระบบ ล้างแคชชั่วคราวทั้งหมดสำหรับปลั๊กอินของคุณ การใช้งานปุ่มนี้โดยทั่วไปมักเกิดขึ้นเมื่อลูกค้าเปลี่ยนข้อมูลบางส่วนโดยตรงบนบริการระยะไกล และต้องการทำให้แคชที่เราจัดเก็บไว้ใน WordPress เป็นโมฆะ ปุ่มนี้อาจมีประโยชน์เช่นกันหากลูกค้าเปลี่ยนข้อมูลประจำตัวของบัญชี คีย์ API หรือปุ่ม "รีเซ็ตเป็นค่าเริ่มต้นจากโรงงาน" สำหรับการดีบัก

แม้ว่าคุณจะฉลาดพอที่จะเนมสเปซคีย์ชั่วคราวทั้งหมดของคุณ เพื่อให้คุณมีความหวังในการระบุแต่ละคีย์สำหรับ 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 ) ในบรรทัดเดียว

ฉันจะสรุปทั้งหมดนี้โดยพูดว่า: คุณไม่สามารถเป็นผู้เชี่ยวชาญในการใช้ API ได้ หากคุณยังไม่เชี่ยวชาญในการจัดการแคชสำหรับข้อมูลนั้น

ในฐานะไคลเอนต์ สิ่งสำคัญที่ต้องระวังคือพฤติกรรมแคชที่ผิดปกติระหว่างสภาพแวดล้อมการจัดเตรียมและการใช้งานจริง กล่าวอีกนัยหนึ่ง แม้ว่าการทดสอบชุดงานใหม่ในการจัดเตรียมจะเป็นแนวทางปฏิบัติที่ดี แต่การแคชก็เป็นสิ่งที่ต้องได้รับการทดสอบในการผลิตด้วยความระมัดระวังเท่าเทียมกัน

API ระยะไกลสามารถช่วยแจ้งลำดับชั้นของคลาส PHP ของคุณ

เมื่อจัดโครงสร้างคลาส PHP ต่างๆ สำหรับปลั๊กอินของฉัน ฉันมักจะพบว่าการเลียนแบบวิธีกำหนดตำแหน่งข้อมูล API นั้นมีประโยชน์ ตัวอย่างเช่น ตำแหน่งข้อมูลต่อไปนี้ดูเหมือนจะมีอะไรที่เหมือนกัน

• 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 ขยายคลาสนามธรรม Collection
• class.campaigns.php ขยายคลาสนามธรรม Collection

คลาสนามธรรมจะใช้เป็นอาร์กิวเมนต์เดียวในอาร์เรย์ของพารามิเตอร์การค้นหา: สิ่งต่างๆ เช่น การแบ่งหน้า คอลัมน์การจัดเรียง ลำดับการจัดเรียง และตัวกรองการค้นหา จะมีวิธีการสำหรับงานทั่วไป เช่น การเรียก API ระยะไกล การจัดการข้อผิดพลาด และอาจปรับเปลี่ยนผลลัพธ์เป็นเมนู HTML <select> หรือ jQueryUI AutoSuggest คลาสที่สร้างอินสแตนซ์คลาสนามธรรมอาจค่อนข้างสั้น อาจทำมากกว่าการระบุสตริงที่จะใช้ใน *.json API endpoint URL เพียงเล็กน้อย

จุดปลายต่อไปนี้มีอะไรที่เหมือนกัน?

• 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 เพียงเล็กน้อย

มีหลายวิธีในการจัดโครงสร้างการสืบทอดคลาส แต่แม้ว่าคุณจะใช้แนวทางที่แตกต่างกับสิ่งที่ฉันได้สรุปไว้ข้างต้น ฉันพนันว่ามีโอกาสดีที่โครงสร้างของ API ระยะไกลสามารถช่วยแจ้งโครงสร้างแอปพลิเคชันของคุณ

ในฐานะไคลเอนต์ อาการทั่วไปของสถาปัตยกรรมที่ไม่ดีคือเมื่อคุณพบว่าตัวเองต้องร้องขอการเปลี่ยนแปลงซ้ำแล้วซ้ำอีกในแอปพลิเคชัน ตัวอย่างเช่น หากคุณขอให้รายงานส่งคืนผลลัพธ์ 100 รายการต่อหน้าแทนที่จะเป็น 10 รายการ และคุณต้องทำซ้ำคำขอนั้นสำหรับรายงานสมาชิก รายงานแคมเปญ รายงานการยกเลิก ฯลฯ คุณอาจตรวจพบสถาปัตยกรรมคลาสที่ไม่ดี ในสถานการณ์นี้ คุณควรถามทีมของคุณว่าพวกเขาจะได้ประโยชน์จากวงจรการปรับโครงสร้างใหม่หรือไม่: เนื้อหางานที่มีเป้าหมายไม่ใช่เพื่อเปลี่ยนพฤติกรรมของผลิตภัณฑ์ แต่ควรปรับปรุงโค้ดพื้นฐานเพื่อให้เปลี่ยนพฤติกรรมได้ง่ายขึ้น ของผลิตภัณฑ์ในอนาคต

กรณีการใช้งานที่สมบูรณ์แบบสำหรับ WP_Error

ฉันอายที่จะยอมรับว่าฉันต้องใช้เวลาหลายปีกว่าที่ควรจะเริ่มใช้ฟังก์ชันตระกูล WP_Error ในโค้ดของฉันอย่างเหมาะสม ฉันมักจะเขียนโค้ดตามทางของฉัน ไม่ว่าจะสมมติว่าไม่มีข้อผิดพลาดที่ควรค่าแก่การดูแลเกี่ยวกับการเขียนโปรแกรมหรือการจัดการเป็นกรณี ๆ ไป การทำงานกับ API ระยะไกลตัดผ่านความคิดนั้นเหมือนลำแสงเลเซอร์ เพราะนำเสนอกรณีการใช้งานที่สะดวกและมีประสิทธิภาพอย่างสูงสุดสำหรับการใช้ WP_Error

จำได้ว่าก่อนหน้านี้ฉันพูดถึงฉันมักจะมีคลาส PHP ซึ่งมีวัตถุประสงค์เพื่อส่งคำขอ HTTP ไปยัง API ระยะไกล เมื่อคุณลอกกลับต้นแบบทั้งหมด การจัดการข้อมูลทั้งหมด ข้อกังวลรองทั้งหมด คลาสนั้นลงมาที่การเรียก wp_remote_request() จริงๆ เพื่อรับวัตถุตอบกลับ HTTP จาก API สะดวก wp_remote_request() จะส่งกลับ WP_Error แทนหากการโทรล้มเหลวในการดำเนินการด้วยเหตุผลบางอย่าง แต่ถ้าการโทรประสบความสำเร็จในการส่งคืนการตอบสนอง HTTP ของประเภทที่ไม่เอื้ออำนวย

ตัวอย่างเช่น เราอาจโทรไปยังปลายทาง /lists.json แต่บัญชีนี้ยังไม่ได้ตั้งค่ารายการใดๆ สิ่งนี้จะส่งคืนการตอบกลับ HTTP ที่ถูกต้อง แต่มีรหัสสถานะ 400 แม้ว่านั่นจะไม่ใช่ข้อผิดพลาดร้ายแรงอย่างแน่นอน จากมุมมองของโค้ดส่วนหน้าบางส่วนที่ต้องการเปลี่ยนการเรียก API นี้เป็นเมนูดรอปดาวน์ 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()

เว็บแบบตั้งโปรแกรมได้สมัยใหม่ ซึ่งเกือบทุกไซต์ใช้ API ของไซต์อื่น ๆ และใช้ตัวมันเองผ่าน API ของตัวเอง ได้กลายเป็นเวทีที่ทรงพลังอย่างเหลือเชื่อสำหรับโค้ด แต่คุณภาพนี้สามารถทำให้มันค่อนข้างช้าได้อย่างแม่นยำ

เป็นเรื่องปกติที่คำขอ HTTP ระยะไกลจะเป็นส่วนที่ใช้เวลานานที่สุดในการโหลดหน้าเว็บที่กำหนด ด้วยเหตุผลนี้ ส่วนประกอบที่ขับเคลื่อนด้วย API จำนวนมากจึงทำงานผ่าน Ajax หรือ cron ตัวอย่างเช่น คำแนะนำอัตโนมัติสำหรับการค้นหาผ่านรายชื่อผู้สมัครรับอีเมลควร ping แหล่งข้อมูลระยะไกลตามต้องการ เมื่อมีการกดแป้นพิมพ์แต่ละครั้ง แทนที่จะโหลดสมาชิกทั้งหมด 100,000 รายภายใน DOM เมื่อหน้าเว็บโหลด หากไม่ใช่ตัวเลือก บางทีแบบสอบถามขนาดใหญ่สามารถซิงโครไนซ์กับงาน cron ทุกคืน เพื่อให้สามารถดึงผลลัพธ์จากมิเรอร์ในเครื่องแทนที่จะเป็น API ระยะไกล

ปัญหาของแนวทางนี้คือ การดีบักอาจทำได้ยาก แทนที่จะเปิดเพียง WP_DEBUG และปล่อยให้ข้อความแสดงข้อผิดพลาดปรากฏในหน้าต่างเบราว์เซอร์ของคุณ คุณกำลังค้นหาในคอนโซลเครือข่ายของเบราว์เซอร์ หรือปรับแต่งไฟล์บันทึกเป็นงาน cron (หวังว่า?) กำลังดำเนินการอยู่ ฉันรู้สึกไม่สบายใจ

วิธีหนึ่งในการปรับปรุงสถานการณ์นี้คือทำการเรียก error_log() อย่างระมัดระวังและเชิงกลยุทธ์ แต่แล้วอีกครั้ง ปัญหาทั่วไปของการบันทึกก็คือสำหรับแอปพลิเคชันขนาดใหญ่หรือไม่ว่าง บันทึกข้อผิดพลาดอาจมีขนาดใหญ่เกินไป หรือเติบโตเร็วเกินไป ซึ่งจะเป็นประโยชน์สำหรับการตรวจสอบหรือการแยกวิเคราะห์ ดังนั้น เราต้องเลือกสิ่งที่เราบันทึก โดยคำนึงถึงสิ่งนั้น มากพอๆ กับที่เราทำกับตรรกะของแอปพลิเคชันจริง น่าเสียดายที่ใช้เวลาในการบันทึกข้อผิดพลาดของ edge case ที่แปลกใหม่ซึ่งดูเหมือนว่าจะเกิดขึ้นเป็นระยะ ๆ ในงาน cron ไม่บ่อยนักเท่านั้นที่จะรู้ว่าธรรมชาติที่แท้จริงของจุดบกพร่องได้หลบเลี่ยงคุณอีกครั้งเพราะคุณล้มเหลวในการบันทึกสมาชิกอาร์เรย์บางคน พูดถึงมูลค่าที่กระทำผิด

ดังนั้น ปรัชญาของฉันจึงกลายเป็น ฉันไม่ได้ล็อกเสมอไป แต่เมื่อฉันทำ ฉันจะบันทึกทุกอย่าง กล่าวอีกนัยหนึ่ง หลังจากระบุฟังก์ชันที่น่าเป็นห่วงเป็นพิเศษแล้ว ฉันจะบันทึกมันโดยใช้เน็ตที่กว้างที่สุดเท่าที่จะทำได้:

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

จำนวนนี้ var_dump() 'ing ค่าบั๊กทั้งหมดเป็นรายการเดียวในไฟล์บันทึกข้อผิดพลาด

ในฐานะลูกค้า การตรวจสอบการใช้งานหน่วยความจำไฟล์ทั้งหมดสำหรับแอปพลิเคชันของคุณเป็นระยะๆ หากคุณสังเกตเห็นว่าจู่ๆ คุณใช้พื้นที่เก็บข้อมูลเกินขีดจำกัดในบัญชีโฮสติ้ง มีโอกาสสูงที่บันทึกข้อผิดพลาดจะหายไป นักพัฒนาของคุณจะได้รับประโยชน์จากวัฏจักรการทำงานที่เน้นไปที่การบันทึกที่ดีขึ้น และลูกค้าของคุณก็จะได้รับประโยชน์เช่นกัน!

ไม่ใช่ Clickbait อย่างแน่นอน แต่จะทำได้

โปรดยกโทษให้โครงสร้างรายการของบทความนี้ ฉันไม่สามารถบังคับประเด็นเหล่านี้ให้เป็นธีมบทความที่เป็นหนึ่งเดียวมากขึ้นได้ เนื่องจากรูปแบบเหล่านี้เป็นแบบทั่วไป: ใช้กับจุดปลาย JSON REST และเอาต์พุตของ WordPress ใดๆ

สิ่งเหล่านี้คือรูปแบบที่ฉันเห็นซ้ำแล้วซ้ำเล่า ไม่ว่า API ระยะไกลคืออะไร หรือสิ่งที่เราใช้สำหรับใน WordPress ฉันได้รวบรวมหลักการเหล่านี้ทั้งหมดลงในเทมเพลตสำเร็จรูปของปลั๊กอินที่ช่วยเร่งงานของฉันได้อย่างมาก คุณมีคะแนนที่คล้ายกันที่คุณเก็บไว้สำหรับแต่ละโครงการหรือไม่? โปรดแบ่งปันเพื่อให้ฉันสามารถขโมยและเพิ่มลงในต้นแบบของฉันได้!