การสร้างปลั๊กอิน WordPress ที่ใช้บริการ API "จากซุปสู่ถั่ว"

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

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

อ่านเพิ่มเติม เกี่ยวกับ SmashingMag:

• WordPress Essentials: วิธีสร้างปลั๊กอิน WordPress
• วิธีการปรับใช้ปลั๊กอิน WordPress ด้วย GitHub โดยใช้ Transients
• แนวทางสามประการในการเพิ่มฟิลด์ที่กำหนดค่าได้ให้กับปลั๊กอินของคุณ

เราจะเริ่มต้นตั้งแต่ต้น แต่จะถือว่ามีความคุ้นเคยกับ WordPress และการพัฒนาปลั๊กอินในระดับหนึ่ง และเราจะไม่ใช้เวลากับหัวข้อเริ่มต้น เช่น การติดตั้ง WordPress หรือ Composer

คุณจะต้องการ:

• สภาพแวดล้อม PHP พร้อมการติดตั้ง WordPress ใหม่
• บัญชี GitHub (หรือผู้ให้บริการ API รายอื่น หากคุณต้องการด้นสด);
• ผู้แต่ง (แนะนำ).

การเลือก API

ขั้นตอนแรกในการเขียนปลั๊กอินประเภทนี้คือการเลือก API ในบทช่วยสอนนี้ เราจะใช้ GitHub API หากคุณกำลังคิดที่จะใช้ API อื่น ให้พิจารณาปัจจัยสำคัญบางประการที่อาจส่งผลต่อการให้รางวัลแก่โครงการของคุณ

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

 // good https://api.stable.com/v1/user/ // danger https://api.dodgy.com/user/

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

ซื้อห้องสมุด

แบรนด์ที่จัดตั้งขึ้นมักจะเผยแพร่ไลบรารีหรือ SDK เพื่อให้ทำงานกับ API ได้ง่ายขึ้น หากไม่เป็นเช่นนั้น อย่าลืมค้นคว้าว่ามีใครเขียนห้องสมุดไว้แล้วก่อนที่คุณจะไปและสร้างวงล้อใหม่ Google และ GitHub เป็นสองสถานที่ที่ยอดเยี่ยมในการเริ่มต้นการวิจัยของคุณ จำนวนดาวหรือส้อมบน GitHub เป็นตัวบ่งชี้ที่ดีว่าห้องสมุดมีประสิทธิภาพเพียงใด อายุของการคอมมิตล่าสุดและ/หรือจำนวนปัญหาที่เปิดอยู่เป็นเครื่องบ่งชี้ว่ามีการคงรักษาไว้อย่างแข็งขันเพียงใด ในกรณีของฉัน ฉันโชคดีที่ได้พบ PHP GitHub API ที่น่ารักโดย KNP Labs

เขียนด้วยตัวคุณเองด้วย Guzzle

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

การตั้งค่าปลั๊กอิน

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

 github-api/ readme.txt github-api.php

readme.txt มีข้อมูลเมตาสำหรับปลั๊กอินของคุณที่จะปรากฏบน wordpress.org หากคุณตัดสินใจที่จะเผยแพร่ที่นั่น อ่านเกี่ยวกับการเผยแพร่ปลั๊กอิน WordPress ในเอกสารประกอบ หรือดูตัวอย่าง readme.txt ที่ครอบคลุม

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

 <?php /** Plugin Name: GitHub API description: >- Add GitHub project information using shortcode Version: 1.0 Author: Your Name License: GPLv2 or later Text Domain: github-api */

ด้วยเหตุผลด้านความปลอดภัย คุณควรปฏิเสธการเข้าถึงไฟล์โดยตรงดังนี้:

 defined( 'ABSPATH' ) or die( 'No script kiddies please!' );

ณ จุดนี้ ปลั๊กอินจะไม่ทำอะไรเลย แต่เมื่อคุณคัดลอกไฟล์ไปยัง wp-content/plugins นั้นควรปรากฏในรายการปลั๊กอิน และคุณควรจะสามารถเปิดใช้งานได้

ต่อไป เราต้องการรวมไลบรารีที่จะจัดการคำขอ API ในตัวอย่างโค้ดต่อไปนี้ เราได้รวม PHP GitHub API ของ KNP Labs ไว้ด้วย แต่คุณสามารถรวมการพึ่งพาใด ๆ ก็ได้โดยการแทนที่ knplabs/github-api ด้วยแพ็คเกจที่คุณใช้

 $ cd wp-content/plugins/github-api $ composer require knplabs/github-api

ตอนนี้ โครงสร้างไฟล์ของคุณควรมีลักษณะดังนี้:

 github-api/ composer.json composer.lock github-api.php readme.txt vendor/

เมื่อไฟล์พร้อมแล้ว เราต้องการ vendor/autoload.php ที่สร้างขึ้นเมื่อคุณติดตั้ง

 require_once 'vendor/autoload.php';

หากทุกอย่างได้รับการตั้งค่าอย่างถูกต้อง คุณควรสร้างอินสแตนซ์ของคลาสจากไลบรารีโดยไม่เกิดข้อผิดพลาดร้ายแรง

 $testing = new \Github\Client();

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

 class MyGithub extends \Github\Client {};

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

WordPress Shortcodes

ตอนนี้ได้เวลาตั้งค่ารหัสย่อแรกของเรา ซึ่งเป็นตัวอย่างพิเศษที่ช่วยให้คุณสร้างเนื้อหาโดยวางไว้ในโพสต์หรือหน้า หากคุณเพิ่งเริ่มใช้รหัสย่อหรือต้องการเข้าใจวิธีการทำงานอย่างลึกซึ้งยิ่งขึ้น โปรดดูเอกสารรหัสย่ออย่างเป็นทางการ ในตัวอย่างของฉัน ฉันจะแสดงรายการปัญหา GitHub ทุกที่ที่ผู้เขียนวางรหัสย่อนี้: [github_issues]

อย่างที่เราทำก่อนหน้านี้ มาเริ่มด้วยตัวอย่างเล็กน้อยเพื่อให้แน่ใจว่ามีการลงทะเบียนรหัสย่ออย่างถูกต้อง ก่อนที่เราจะดำเนินการเรียก API

 function github_issues_func( $atts ) { return "Hello world!"; } add_shortcode( "github_issues", "github_issues_func" );

ตอนนี้ หากคุณเผยแพร่หน้าที่มี [github_issues] คุณจะเห็น “สวัสดีชาวโลก” เมื่อคุณเยี่ยมชมหน้านั้น ตอนนี้ใช้งานได้แล้ว มาตั้งค่าการเรียก API กัน

ในส่วนก่อนหน้านี้ เราได้ตั้งค่าการโหลดอัตโนมัติสำหรับไลบรารี GitHub และกำหนดคลาสของเราเองเพื่อขยาย ตอนนี้ เราสามารถเริ่มใช้มันเพื่อเรียก API ได้แล้ว ดังนั้น เราจะเพิ่มลงในฟังก์ชันเรียกกลับของรหัสย่อ เพื่อเป็นการพิสูจน์แนวคิด เรามาดึงปัญหาทั้งหมดในที่เก็บ GitHub Pipeline กัน มีเอกสารประกอบสำหรับวิธีนี้

 function github_issues_func( $atts ) { // Instantiate our class $gh = new MyGithub(); // Make the API call to get issues, passing in the GitHub owner and repository $issues = $gh->api('issue')->all('TransitScreen', 'wp-github-pipeline'); // Handle the case when there are no issues if ( empty($issues) ) return "<strong>" . __("No issues to show", 'githup-api') . "</strong>"; // We're going to return a string. First, we open a list. $return = "<ul>"; // Loop over the returned issues foreach( $issues as $issue ) { // Add a list item for each issue to the string // (Feel free to get fancier here) // Maybe make each one a link to the issue issuing $issue['url] ) $return .= "<li>{$issue['title']}</li>"; } // Don't forget to close the list $return .= "</ul>"; return $return; } add_shortcode( 'github_issues', 'github_issues_func' );

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

 function github_issues_func( $atts, $gh=null ) { // Conditionally instantiate our class $gh = ( $gh ) ? $gh : new MyGithub(); …

การปรับเปลี่ยนนี้คล้ายกับรูปแบบการฉีดขึ้นต่อกัน ซึ่งทำให้ฟังก์ชันของเราทดสอบได้ง่ายขึ้นมาก การทดสอบหน่วยของ WordPress อยู่นอกเหนือขอบเขตของบทช่วยสอนนี้ แต่ง่ายต่อการดูว่าเวอร์ชันใหม่นี้ช่วยให้เราส่งข้อมูล API "ปลอม" ไปยังฟังก์ชันได้ง่ายเพียงใด เพื่อให้การยืนยันการทดสอบของเราทราบว่าจะเกิดอะไรขึ้น

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

ขั้นแรก เราจะใช้ WordPress hook เพื่อลงทะเบียนหน้าการตั้งค่าใหม่ของเรา และฟังก์ชันการโทรกลับจะกำหนดป้ายกำกับและชื่อของเมนู เราจะใช้วิธีการที่เพิ่มขึ้นแบบเดียวกันเพื่อให้มันทำงาน

 // Register the menu. add_action( "admin_menu", "gh_plugin_menu_func" ); function gh_plugin_menu_func() { add_submenu_page( "options-general.php", // Which menu parent "GitHub", // Page title "GitHub", // Menu title "manage_options", // Minimum capability (manage_options is an easy way to target administrators) "github", // Menu slug "gh_plugin_options" // Callback that prints the markup ); } // Print the markup for the page function gh_plugin_options() { if ( !current_user_can( "manage_options" ) ) { wp_die( __( "You do not have sufficient permissions to access this page." ) ); } echo "Hello world!"; }

ตอนนี้ คุณควรจะสามารถเข้าสู่แดชบอร์ดและเห็นเมนู GitHub ใหม่ภายใต้ “การตั้งค่า” จากนั้นคลิกเพื่อดูหน้าการตั้งค่าว่างที่มีคำว่า “สวัสดีชาวโลก!”

ต่อไป เราจะแทนที่ Hello word ด้วยมาร์กอัปของแบบฟอร์ม ฉันจะยกตัวอย่างแบร์โบนให้คุณซึ่งคุณสามารถจัดสไตล์ได้น้อยหรือมากเท่าที่คุณต้องการ

 ?> <form method="post" action="<?php echo admin_url( 'admin-post.php'); ?>"> <input type="hidden" name="action" value="update_github_settings" /> <h3><?php _e("GitHub Repository Info", "github-api"); ?></h3> <p> <label><?php _e("GitHub Organization:", "github-api"); ?></label> <input class="" type="text" name="gh_org" value="<?php echo get_option('gh_org'); ?>" /> </p> <p> <label><?php _e("GitHub repository (slug):", "github-api"); ?></label> <input class="" type="text" name="gh_repo" value="<?php echo get_option('gh_repo'); ?>" /> </p> <input class="button button-primary" type="submit" value="<?php _e("Save", "github-api"); ?>" /> </form> <?php

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

มีสองสิ่งสำคัญที่ต้องทำความเข้าใจเกี่ยวกับแบบฟอร์มนี้ ขั้นแรก ปลายทางที่จะส่งจะต้องเป็น /wp-admin/admin-post.php คุณสามารถฮาร์ดโค้ดพาธนี้ได้ แต่ถ้าติดตั้งเว็บไซต์ในไดเร็กทอรีย่อยจะไม่ทำงาน ดังนั้นเราจึงใช้ admin_url() ในตัวเพื่อสร้างแบบไดนามิก

ประการที่สอง สังเกตอินพุตที่ซ่อนอยู่ด้วยการ action ชื่อ ฟิลด์นี้เป็นวิธีที่ WordPress รู้ว่าต้องทำอย่างไรกับคำขอโพสต์ที่ส่งโดยแบบฟอร์ม value นี้สอดคล้องกับชื่อของ action hook ที่เราจะใช้ในการตั้งค่าฟังก์ชันการเรียกกลับ ชื่อของการดำเนินการที่เราจะขอใช้จะเป็นค่านี้ นำหน้าด้วย admin post ดังนั้น ในกรณีของเรา เราจำเป็นต้องเพิ่มสิ่งนี้:

 add_action( 'admin_post_update_github_settings', 'github_handle_save' );

ฉันพบว่าสิ่งนี้เป็นหนึ่งในแง่มุมที่แปลกใหม่และใช้งานง่ายน้อยกว่าในการสร้างเมนูการดูแลระบบแบบกำหนดเอง แต่เมื่อคุณชินกับมันแล้ว ก็ไม่เจ็บปวดเลย อย่างที่คุณอาจเดาได้ พารามิเตอร์ตัวที่สองของ add_action() คือชื่อของฟังก์ชันเรียกกลับของเราที่จะบันทึกค่าลงในฐานข้อมูล

 function github_handle_save() { // Get the options that were sent $org = (!empty($_POST["gh_org"])) ? $_POST["gh_org"] : NULL; $repo = (!empty($_POST["gh_repo"])) ? $_POST["gh_repo"] : NULL; // Validation would go here // Update the values update_option( "gh_repo", $repo, TRUE ); update_option("gh_org", $org, TRUE); // Redirect back to settings page // The ?page=github corresponds to the "slug" // set in the fourth parameter of add_submenu_page() above. $redirect_url = get_bloginfo("url") . "/wp-admin/options-general.php?page=github&status=success"; header("Location: ".$redirect_url); exit; }

ตัวอย่างยังค่อนข้างน้อย ในการตั้งค่าการผลิต คุณอาจต้องการเพิ่มการตรวจสอบ นอกจากนี้ ในตัวอย่างนี้ เรากำลังส่งกลับ status=success ไปยัง URL โดยอัตโนมัติ มาร์กอัปของแบบฟอร์มยังไม่ได้ใช้งานจริง หากต้องการแสดงข้อความแสดงความสำเร็จแบบมีเงื่อนไข ให้เพิ่มสิ่งต่อไปนี้เหนือแบบฟอร์มใน gh_plugin_options() :

 if ( isset($_GET['status']) && $_GET['status']=='success') { ?> <div class="updated notice is-dismissible"> <p><?php _e("Settings updated!", "github-api"); ?></p> <button type="button" class="notice-dismiss"> <span class="screen-reader-text"><?php _e("Dismiss this notice.", "github-api"); ?></span> </button> </div> <?php }

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

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

 … $issues = $gh->api("issue")->all(get_option("gh_org"), get_option("gh_repo")); …

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

รอบโบนัส: การตรวจสอบสิทธิ์ OAuth 2.0

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

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

เราจะเริ่มต้นด้วยการลงทะเบียนแอปพลิเคชันกับ GitHub เช่นเดียวกับ API ที่ได้รับความนิยมส่วนใหญ่ ส่วนนี้จะอยู่ในพื้นที่สำหรับนักพัฒนาของเว็บไซต์

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

ต่อไป เราจะเพิ่มแบบฟอร์มที่สองในหน้าการตั้งค่าของเรา ใน gh_plugin_options() เพื่อส่งรหัสลูกค้าและข้อมูลลับของแอปพลิเคชัน

 <form method="post" action="<?php echo admin_url( 'admin-post.php'); ?>"> <input type="hidden" name="action" value="oauth_submit" /> <h3>Oauth 2.0</h3> <p> <label><?php _e("GitHub Application Client ID:", "github-api"); ?></label> <input class="" type="text" name="client_id" value="<?php echo get_option('client_id')?>" /> </p> <p> <label><?php _e("GitHub Application Client Secret:", "github-api"); ?></label> <input class="" type="password" name="client_secret" value="<?php echo get_option('client_secret')?>" /> </p> <input class="button button-primary" type="submit" value="<?php _e("Authorize", "github-api"); ?>" /> </form>

เพื่อให้ชีวิตง่ายขึ้น ฉันจะใช้ GitHub Provider for OAuth 2.0 Client โดย The League of Extraordinary Packages ก่อนอื่น ลองใช้ Composer อีกครั้งเพื่อเพิ่มการพึ่งพา:

 composer require league/oauth2-github

โปรดทราบว่าไลบรารี GitHub จาก KNP Labs มีการรองรับ OAuth 2.0 ในตัว ดังนั้นในตัวอย่างเฉพาะของฉัน สิ่งนี้ค่อนข้างซ้ำซ้อน แต่ฉันอยากจะแนะนำไลบรารีนี้เนื่องจากเป็นชุดของไลบรารีไคลเอ็นต์ OAuth 2.0 เฉพาะผู้ให้บริการ ซึ่งทั้งหมดขยายเฟรมเวิร์กเดียวกันที่ดูแลโดย League of Extraordinary Packages อันทรงพลัง คุณสามารถดูรายชื่อผู้ให้บริการที่รองรับทั้งหมดหรืออ่านคำแนะนำเกี่ยวกับวิธีขยายกรอบงานเพื่อรองรับผู้ให้บริการรายใหม่

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

 function handle_oauth() { // If the form was just submitted, save the values // (Step 1 above) if ( isset($_POST["client_id"]) && isset($_POST["client_secret"]) ) { update_option( "client_id", $_POST["client_id"], TRUE ); update_option("client_secret", $_POST["client_secret"], TRUE); } // Get the saved application info $client_id = get_option("client_id"); $client_secret = get_option("client_secret"); if ($client_id && $client_secret) { $provider = new League\OAuth2\Client\Provider\Github([ "clientId" => $client_id, "clientSecret" => $client_secret, "redirectUri" => admin_url("options-general.php?page=github"), ]); } // If this is a form submission, start the workflow // (Step 2) if (!isset($_GET["code"]) && $_SERVER["REQUEST_METHOD"] === "POST") { // If we don't have an authorization code, then get one $authUrl = $provider->getAuthorizationUrl(); $_SESSION["oauth2state"] = $provider->getState(); header("Location: ".$authUrl); exit; // Check given state against previously stored one to mitigate CSRF attack // (Step 3 just happened and the user was redirected back) } elseif (empty($_GET["state"]) || ($_GET["state"] !== $_SESSION["oauth2state"])) { unset($_SESSION["oauth2state"]); exit("Invalid state"); } else { // Try to get an access token (using the authorization code grant) // (Step 4) $token = $provider->getAccessToken("authorization_code", [ "code" => $_GET["code"] ]); // Save the token for future use update_option( "github_token", $token->getToken(), TRUE ); } }

และเช่นเดียวกับที่เราทำกับแบบฟอร์มอื่น เราจำเป็นต้องเพิ่ม action hook เพื่อให้ฟังก์ชันถูกเรียกใช้เมื่อบันทึกแบบฟอร์ม

 add_action( "admin_post_oauth_submit", "handle_oauth" );

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

 $gh = new MyGithub(); $gh->authenticate( get_option("github_token"), NULL, Github\Client::AUTH_HTTP_TOKEN);

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

บทสรุป

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

บันทึกสุดท้าย

• WordPress Codex (เอกสารประกอบ)
• GitHub API (เอกสารประกอบ)
• OAuth 2.0 (เอกสารประกอบ)
• ผู้แต่ง (เอกสารประกอบ)
• ลีกแห่งแพ็คเกจพิเศษ
• เอกสาร Guzzle