วิธีเข้าถึงการพัฒนา WordPress สมัยใหม่ (ตอนที่ 2)

เผยแพร่แล้ว: 2022-03-11

WordPress เป็นเทคโนโลยีเว็บไซต์ที่ใช้กันอย่างแพร่หลายมากที่สุดในโลกและมีเหตุผลที่ดี ทว่ารหัสดั้งเดิมในแกนกลางนั้นไม่เป็นระเบียบ และปัญหานี้ก็ตกทอดไปยังนักพัฒนาบุคคลที่สาม นักพัฒนาบางคนใช้สิ่งนี้เป็นข้ออ้างในการตัดมุมในโค้ด WordPress PHP ของพวกเขาเอง แต่วิธีนี้มีราคาแพงกว่าในระยะยาวสำหรับทุกคน ยกเว้นการเปลี่ยนแปลงเล็กน้อยที่สุด

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

ดังนั้น หลักการออกแบบซอฟต์แวร์สมัยใหม่และคุณสมบัติ PHP ใดและจะให้คุณค่าที่ดีที่สุดสำหรับเวลาของคุณ? ต่อไปนี้เป็นแนวทางปฏิบัติในการพัฒนา 10 WordPress และ PHP ที่ฉันแนะนำเป็นอย่างยิ่ง

แนวทางปฏิบัติที่ดีที่สุดสำหรับการพัฒนา WordPress สมัยใหม่ #1: ปฏิบัติตาม “การแยกข้อกังวล”

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

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

นั่นค่อนข้างจะพูดได้เต็มปาก ดังนั้นเรามาดูตัวอย่างของ WordPress PHP (จาก WordPress core) ที่ทำให้ทุกอย่างพันกัน การเขียนโค้ดแบบนี้มักเรียกว่า "รหัสสปาเก็ตตี้" เพราะแทบจะเป็นไปไม่ได้เลยที่จะเข้าใจการทำงานภายในของมัน ข้อความที่ตัดตอนมาด้านล่างถูกแก้ไขเพื่อให้กระชับ อย่างไรก็ตาม รูปแบบและการจัดรูปแบบเดิมยังคงอยู่

 $id = isset( $_REQUEST['id'] ) ? intval( $_REQUEST['id'] ) : 0; <table class="form-table"> <?php $blog_prefix = $wpdb->get_blog_prefix( $id ); $sql = "SELECT * FROM {$blog_prefix}options WHERE option_name NOT LIKE %s AND option_name NOT LIKE %s"; $query = $wpdb->prepare( $sql, $wpdb->esc_like( '_' ) . '%', '%' . $wpdb->esc_like( 'user_roles' ) ); $options = $wpdb->get_results( $query ); foreach ( $options as $option ) { if ( strpos( $option->option_value, "\n" ) === false ) { ?> <tr class="form-field"> <th scope="row"><label for="<?php echo esc_attr( $option->option_name ); ?>"><?php echo esc_html( ucwords( str_replace( '_', ' ', $option->option_name ) ) ); ?></label></th> <?php if ( $is_main_site && in_array( $option->option_name, array( 'siteurl', 'home' ) ) ) { ?> <td><code><?php echo esc_html( $option->option_value ); ?></code></td> <?php } else { ?> <td><input class="<?php echo $class; ?>" name="option[<?php echo esc_attr( $option->option_name ); ?>]" type="text" value="<?php echo esc_attr( $option->option_value ); ?>" size="40" <?php disabled( $disabled ); ?> /></td> <?php } ?> </tr> <?php } } // End foreach </table>

ประการแรก มันไม่สามารถเข้าใจได้โดยสิ้นเชิง และฉันชอบที่ความคิดเห็นเดียวคือ End foreach ซึ่งซ้ำซ้อนโดยสิ้นเชิง เรามีการสืบค้นฐานข้อมูล การประมวลผลผลลัพธ์ของแบบสอบถาม การประมวลผลเพิ่มเติมที่ฝังอยู่ใน HTML (มี if / else ซ้อนอยู่ที่นั่นหากคุณไม่ได้สังเกต) การหลบหนีเอาต์พุต และการสร้างเทมเพลต HTML ทั้งหมดมารวมกัน ปัญหาอีกประการหนึ่งคือพารามิเตอร์ $id ที่ส่งตรงมาจาก $_REQUEST ทั่วโลก แทนที่จะส่งพารามิเตอร์จริงไปยังฟังก์ชัน

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

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

  • แบบสอบถาม SQL ควรอยู่ในโมดูลแยกต่างหากอย่างชัดเจน WordPress มีคลาส WP_Query ที่เป็นนามธรรมอยู่แล้วซึ่งควรใช้เป็นตัวอย่าง
  • HTML ทั้งหมดจะเข้าสู่เทมเพลต เราจะกล่าวถึงการสร้างเทมเพลต PHP ด้านล่าง
  • โค้ด PHP ที่เหลือควรรวมไว้ในฟังก์ชัน—หลายฟังก์ชัน หากโค้ดยาวเกินไปหรือซับซ้อนเกินไปสำหรับฟังก์ชันเดียว พารามิเตอร์เช่น $id ถูกส่งผ่านอาร์กิวเมนต์ของฟังก์ชัน

นี่คือการเขียนใหม่อย่างง่ายอย่างมากจากตัวอย่างข้างต้น:

 function betterSiteSettings($args) { $data = WP_Settings_Query($args); // process $data here $context = array_merge([], $data_processed, $other_data); return Template::render('template.name', $context); }

แนวทางปฏิบัติที่ดีที่สุดสำหรับการพัฒนา WordPress สมัยใหม่ #2: หลีกเลี่ยงตัวแปรทั่วโลก

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

ลองดูสิ่งนี้จากมุมที่ใช้งานได้จริง ตัวอย่างนี้มาจาก WooCommerce อาจเป็นไปได้ว่านักพัฒนา WordPress ทุกคนรู้ว่ามันคืออะไร — the Loop:

 <?php while ( have_posts() ) : the_post(); ?> <?php wc_get_template_part( 'content', 'single-product' ); ?> <?php endwhile; // end of the loop. ?>

ข้อมูลโค้ดด้านบนแสดงเทมเพลตผลิตภัณฑ์ มันรู้ได้อย่างไรว่าจะแสดงผลิตภัณฑ์ใดเนื่องจากไม่มีพารามิเตอร์ที่ส่งผ่านไปยัง wc_get_template_part เมื่อดูที่เทมเพลต เราจะเห็นว่ามันเริ่มต้นด้วย global $product; นั่นคือตำแหน่งที่เก็บวัตถุผลิตภัณฑ์ปัจจุบัน

ลองนึกภาพว่าเรามีหน้าแค็ตตาล็อกที่ค้นหาและกรองผลิตภัณฑ์ และเราต้องการแสดงป๊อปอัป "รายละเอียดสินค้า" โดยคงอยู่ในหน้าเดียวกัน เบื้องหลัง สคริปต์ส่วนหน้าร้องขอ AJAX เพื่อรับเทมเพลตผลิตภัณฑ์นั้น ๆ เราไม่สามารถเรียก wc_get_template_part('content', 'single-product') ได้ง่ายๆ เพราะมันไม่ได้ใช้พารามิเตอร์ ดังนั้นเราจึงต้องตั้งค่าตัวแปรโกลบอลสองสามตัวเพื่อให้สิ่งนี้ทำงาน

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

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

แนวทางปฏิบัติที่ดีที่สุดสำหรับการพัฒนา WordPress สมัยใหม่ #3: ใช้การเขียนโปรแกรมเชิงวัตถุ (OOP)

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

หลักการสำคัญใน OOP คือการจำกัดการเข้าถึงเมธอดและคุณสมบัติ—หรือในเงื่อนไข PHP แสดงว่าเป็น private หรือแบบ protected —ดังนั้นเฉพาะเมธอดของคลาสอื่นเท่านั้นที่สามารถเข้าถึงและเปลี่ยนแปลงได้ คำศัพท์ OOP สำหรับสิ่งนี้คือการ ห่อหุ้ม : ข้อมูลถูกห่อหุ้มไว้ภายในคลาส และวิธีเดียวในการเปลี่ยนแปลงข้อมูลนั้นคือการใช้วิธีคลาสที่ให้ไว้

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

นี่เป็นเพียงคำอธิบายเบื้องต้นของ OOP และวิธีการใช้ในการพัฒนา WordPress สมัยใหม่ สำหรับการศึกษาเพิ่มเติม ฉันแนะนำ e-book ของ Carl Alexander อย่างละเอียด นั่นคือ Discover Object-Oriented programming โดยใช้ WordPress ซึ่งมีเนื้อหาที่ครอบคลุมและมีประโยชน์มากที่สุดในหัวข้อ OOP ใน WordPress

สิ่งสำคัญที่ต้องจำไว้คือ OOP ไม่ใช่สัญลักษณ์แสดงหัวข้อย่อยสีเงิน: สามารถเขียนโค้ดที่ไม่ถูกต้องด้วย OOP ได้อย่างง่ายดายเหมือนกับกระบวนทัศน์การเขียนโปรแกรมอื่นๆ

มาดูคำแนะนำเฉพาะเกี่ยวกับการใช้ PHP สำหรับการพัฒนา WordPress กัน

แนวปฏิบัติที่ดีที่สุดของ PHP สมัยใหม่ #1: กำหนดเป้าหมาย PHP 7.0+

การใช้คุณลักษณะ PHP ที่ทันสมัยจำเป็นต้องมี PHP เวอร์ชันใหม่ ไม่มีเหตุผลรองรับ PHP เวอร์ชันที่ต่ำกว่า 7.0 แม้แต่คอร์ของ WordPress ก็ยังต้องใช้ PHP 7.0 ก่อนสิ้นปี 2019

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

 <?php /** * Plugin Name: My Awesome Plugin * Requires PHP: 7.0 */ // bails if PHP version is lower than required if (version_compare(PHP_VERSION, '7.0.0', '<')) { // add admin notice here return; } // the rest of the actual plugin here

แนวปฏิบัติที่ดีที่สุดของ PHP สมัยใหม่ #2: ใช้มาตรฐานอุตสาหกรรม PHP (คู่มือรูปแบบการเข้ารหัส PSR-2)

PSR คือคำแนะนำที่เผยแพร่โดย PHP Framework Interop Group เป็นมาตรฐานอุตสาหกรรมโดยพฤตินัยในเวิร์กโฟลว์ PHP สมัยใหม่ และสามารถพูดได้อย่างปลอดภัยว่าชุมชน PHP ทั้งหมดปฏิบัติตามมาตรฐานเหล่านี้ PSR-2 เป็นคำแนะนำที่อธิบายรูปแบบการเข้ารหัส เฟรมเวิร์ก PHP ยอดนิยม เช่น Symfony และ Laravel เป็นไปตาม PSR-2

ทำไมคุณถึงใช้ PSR-2 แทนมาตรฐานการเข้ารหัสของ WordPress? สาเหตุหลักเนื่องจากมาตรฐานของ WordPress นั้นล้าสมัยและไม่ได้ใช้คุณสมบัติภาษาที่ใหม่กว่า เป็นเรื่องที่เข้าใจได้เพราะแกนหลักของ WordPress ต้องเป็นไปตามมาตรฐานของตัวเอง ต้องรองรับ PHP 5.2 จนกระทั่งเมื่อไม่นานมานี้ และ PSR-2 ไม่รองรับ PHP 5.2

อาจไม่ชัดเจน แต่ก็ไม่จำเป็นต้องใช้มาตรฐานการเข้ารหัสของ WordPress เว้นแต่คุณจะผูกมัดกับแกนหลัก จะไม่มีปัญหาในการส่งปลั๊กอินที่เป็นไปตามมาตรฐาน PSR-2 ไปยังไดเร็กทอรีปลั๊กอินของ WordPress อันที่จริง มีข้อโต้แย้งที่ดีมากสำหรับการทำเช่นนั้น

Modern PHP Best Practice #3: ใช้ PHP Template Engine

PHP ไม่ใช่เครื่องมือเทมเพลต มันเริ่มต้นเป็นหนึ่งเดียว แต่จากนั้นก็พัฒนาเป็นภาษาการเขียนโปรแกรมที่มีคุณสมบัติครบถ้วน และไม่มีเหตุผลที่จะใช้มันสำหรับการสร้างเทมเพลตต่อไป เทมเพลตเอ็นจิ้นยอดนิยมสองแบบสำหรับ PHP คือ Twig และ Blade ซึ่งใช้โดย Symfony และ Laravel ตามลำดับ บทความนี้จะใช้ทวิกเป็นเครื่องมือสร้างเทมเพลตตัวอย่าง อย่างไรก็ตาม Blade มีคุณสมบัติและฟังก์ชันที่เทียบเท่ากัน ฉันขอให้คุณพิจารณาทั้งสองอย่างและตัดสินใจด้วยตัวเองว่าแบบไหนเหมาะกับคุณที่สุด

ตัวอย่างด้านล่างเปรียบเทียบเทมเพลต PHP กับเทมเพลต Twig ที่เกี่ยวข้อง การแสดงและการหลีกเลี่ยงเอาต์พุตนั้นละเอียดมากในตัวอย่าง PHP:

 foreach ( $options as $option ) { ?> <tr class="form-field"> <th scope="row"> <label for="<?php echo esc_attr( $option->option_name ); ?>"> <?php echo esc_html( strtolower( $option->option_name ) ); ?> </label> </th> </tr> <?php } // End foreach

ใน Twig สิ่งนี้กระชับและอ่านง่ายยิ่งขึ้น:

 {% for option in options %} <tr class="form-field"> <th scope="row"> <label for="{{ option.option_name }}"> {{ option.option_name }} </label> </th> </tr> {% endfor %}

ข้อได้เปรียบหลักของทวิกคือ:

  • ไวยากรณ์ที่อ่านง่ายและกระชับ
  • หลบหนีเอาต์พุตอัตโนมัติ
  • ส่วนขยายเทมเพลตผ่านการสืบทอดและบล็อก

ในแง่ของประสิทธิภาพ Twig จะคอมไพล์ไปยังเทมเพลต PHP และแทบไม่มีโอเวอร์เฮด Twig มีเพียงชุดย่อยของโครงสร้างภาษา PHP ที่จำกัดเฉพาะการสร้างเทมเพลตเท่านั้น สิ่งนี้บังคับให้นักพัฒนาลบตรรกะทางธุรกิจออกจากเทมเพลต ดังนั้นจึงบังคับให้แยกข้อกังวลออก

มีแม้กระทั่ง Twig สำหรับ WordPress เรียกว่า Timber และเป็นวิธีที่ยอดเยี่ยมในการเริ่มต้นสร้างเทมเพลตที่ดีขึ้น ธีมเริ่มต้นของ Timber เป็นตัวอย่างที่สมบูรณ์แบบของการจัดระเบียบธีมด้วยวิธี OOP

Modern PHP Best Practice #4: ใช้ Composer

Composer เป็นผู้จัดการการพึ่งพาสำหรับ PHP เป็นเครื่องมือที่อนุญาตให้ประกาศไลบรารีที่โปรเจ็กต์ใช้อยู่ จากนั้นทำการดาวน์โหลด ติดตั้งและอัปเดตโดยอัตโนมัติ จากนั้น คุณเพียงแค่ต้องรวม autoload file vendor/autoload.php ของ Composer แทนการกำหนดให้แต่ละไลบรารี่เอง

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

เพื่อหลีกเลี่ยงความขัดแย้ง ควรใช้การจัดการการพึ่งพาในระดับแอปพลิเคชัน กล่าวคือ ไซต์ WordPress โดยรวม นี่คือสิ่งที่ Roots (Bedrock เจาะจงมากขึ้น) ทำ เมื่อใช้ในระดับแพ็คเกจ (ปลั๊กอินหรือธีม) Composer อาจทำให้เกิดข้อขัดแย้งเมื่อใช้ไลบรารีของบุคคลที่สาม เป็นปัญหาที่ทราบ ทางออกเดียวที่มีอยู่ตอนนี้คือการเปลี่ยนชื่อเนมสเปซของไลบรารีภายนอกเป็นสิ่งที่ไม่เหมือนใคร และนั่นไม่ใช่งานเล็กน้อย

ยังคงมีการใช้งานสำหรับ Composer: การโหลดอัตโนมัติของคลาสของคุณเอง แต่ก่อนที่เราจะทำการโหลดอัตโนมัติต่อไป เราต้องเร่งความเร็วด้วยเนมสเปซ PHP

Modern PHP Best Practice #5: ใช้เนมสเปซ

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

การชนกันของการตั้งชื่อ (เช่น การประกาศฟังก์ชันด้วยชื่อที่มีอยู่แล้ว) มักจะนำไปสู่หน้าจอสีขาวแห่งความตาย และเราไม่ต้องการสิ่งนั้น WordPress Codex แนะนำให้เติมคำนำหน้าฟังก์ชันและคลาสทั้งหมดของคุณด้วยบางสิ่งที่ไม่เหมือนใคร ดังนั้นแทนที่จะมีชื่อคลาสง่าย ๆ เช่น Order เราได้ Akrte_Awesome_Plugin_Order โดยที่ “Akrte” เป็นคำนำหน้าเฉพาะที่ฉันเพิ่งสร้างขึ้น

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

ส่วนเนมสเปซเหล่านี้เรียกว่าเนมสเปซย่อย ตัวอย่างคลาส Akrte_Awesome_Plugin_Order ของเราคือ Akrte\Awesome_Plugin\Order หากทำโดยใช้เนมสเปซ ที่นี่ Akrte และ Awesome_Plugin เป็นส่วนของเนมสเปซ (หรือเนมสเปซย่อย) และ Order คือชื่อคลาส จากนั้นคุณสามารถเพิ่มคำสั่ง use และใช้เฉพาะชื่อคลาสในภายหลัง มันดูดีกว่าอย่างแน่นอน:

 use Akrte\Awesome_Plugin\Order; $a = new Order;

แน่นอน เนมสเปซควรไม่ซ้ำกัน ดังนั้น เราควรตั้งชื่อเฉพาะให้กับเนมสเปซย่อย "รูท" ตัวแรก และนั่นก็มักจะเป็นชื่อผู้ขาย ตัวอย่างเช่น คลาส WooCommerce WC_REST_Order_Notes_V2_Controller สามารถทำได้อีกครั้งด้วยเนมสเปซดังนี้:

 namespace WooCommerce\RestApi\V2\Controllers; class OrderNotes {}

โค้ดเบสของ WooCommerce ในปัจจุบันใช้เนมสเปซ ตัวอย่างเช่น ใน WooCommerce REST API เวอร์ชัน 4

Modern PHP Best Practice #6: ใช้ตัวโหลดอัตโนมัติ

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

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

ฟังก์ชันโหลดอัตโนมัติจำเป็นต้องรู้ว่าไฟล์ใดที่คลาสและฟังก์ชันของคุณใช้งานอยู่ และมีมาตรฐาน PHP-FIG คือ PSR-4 สำหรับสิ่งนั้น

มันบอกว่าส่วนหนึ่งของเนมสเปซ คำนำหน้า ถูกกำหนดให้สอดคล้องกับโฟลเดอร์ฐาน เนมสเปซย่อยที่ตามมาจะสัมพันธ์กับโฟลเดอร์ภายในโฟลเดอร์ฐาน สุดท้าย ชื่อคลาสจะสอดคล้องกับชื่อไฟล์ ตัวอย่างคลาส Akrte\AwesomePlugin\Models\Order จะต้องมีโครงสร้างโฟลเดอร์ด้านล่าง:

 /awesome-plugin awesome-plugin.php /includes /Models Order.php

คำนำหน้าเนมสเปซ Akrte\AwesomePlugin\ สอดคล้องกับโฟลเดอร์ includes ตามที่ระบุในการกำหนดค่าตัวโหลดอัตโนมัติที่กล่าวถึงด้านล่าง เนมสเปซย่อย Models มีโฟลเดอร์ Models ที่สอดคล้องกัน และคลาส Order มีอยู่ใน Order.php

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

  1. ติดตั้งผู้แต่ง
  2. สร้างไฟล์ composer.json ในโฟลเดอร์รูทของโปรเจ็กต์ของคุณ ควรมีบรรทัดเหล่านี้:
 { "name": "vendor-name/plugin-name", "require": {}, "autoload": { "psr-4": { "Akrte\\AwesomePlugin\\": "includes/" } } }
  1. เรียกใช้ composer install
  2. รวม vendor/autoload.php ไว้ที่ด้านบนของไฟล์ PHP ของปลั๊กอินหลักดังนี้:
 <?php /** * Plugin Name: My Awesome Plugin */ defined('ABSPATH') || exit; require __DIR__ . '/vendor/autoload.php'; // do stuff

นอกจากเนมสเปซแล้ว Codebase ล่าสุดของ WooCommerce ยังใช้ตัวโหลดอัตโนมัติของ Composer

ด้วยหลักการออกแบบ PHP เหล่านี้ ถึงเวลาที่จะเชื่อมโยงบทเรียน PHP ทั้งหมดของเรากับการปรับแต่งส่วนหลังของ WordPress ด้วยคำแนะนำสุดท้าย

แนวทางปฏิบัติที่ดีที่สุดสำหรับการพัฒนา WordPress สมัยใหม่ #4: พิจารณาใช้ Roots Stack

Roots เป็นเวิร์กโฟลว์การพัฒนา WordPress ที่ทันสมัยที่สุดที่มี อย่างไรก็ตาม ฉันจะบอกว่ามันไม่จำเป็นต้องใช้ใน ทุก โครงการของ WordPress เพราะ:

  • ต้องใช้รากตั้งแต่เริ่มต้น สาเหตุที่พบบ่อยที่สุดจริงๆ การปรับโครงสร้างโครงการที่มีอยู่ใหม่จะมีค่าใช้จ่ายสูงเกินไป
  • มันออกความเห็น ดีเมื่อคุณเห็นด้วย ไม่ดีเมื่อคุณไม่ทำ คุณอาจต้องการวิธีอื่นๆ ในการจัดธีมของคุณ เป็นต้น โครงการที่คิดเห็นยังต้องใช้เวลาในการเรียนรู้ “แนวทางของพวกเขา”
  • ไม่ใช่ทุกคนที่รู้ นักพัฒนาที่จะติดตามคุณเพื่อรักษาไซต์ที่คุณสร้างด้วย Roots stack อาจไม่รู้ว่ามันคืออะไรและสงสัยว่าเกิดอะไรขึ้นกับโฟลเดอร์ WordPress เราควรนึกถึงนักพัฒนา WordPress คนอื่นๆ ของเรา

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

หลักการ PHP และซอฟต์แวร์สมัยใหม่: ทำให้ WordPress Back-end Development แข็งแกร่ง

ค่อนข้างชัดเจนว่าไม่มีวิธีเขียนซอฟต์แวร์ที่ แท้จริง แนวความคิด เช่น การแยกข้อกังวล มีมานานหลายทศวรรษ อย่างไรก็ตามความหมายในทางปฏิบัติมักถูกโต้แย้งอยู่เสมอ ยกตัวอย่าง CSS ในตอนเริ่มต้น เราใส่ style ลงใน HTML จากนั้นจึงตัดสินใจว่าชีต CSS ที่แยกจากกันเป็นสิ่งที่แยกจากข้อกังวล

กรอไปข้างหน้าอย่างรวดเร็วในทศวรรษ: แอป JavaScript ในปัจจุบันใช้ ส่วนประกอบ ต่างๆ นักพัฒนา Front-end หันไปหา CSS-in-JS และนั่นหมายถึงการใส่ CSS ใน HTML อีกครั้ง (มันไม่ง่ายขนาดนั้น แต่คุณก็เข้าใจแล้ว) ครบวงจร!

แนวทางปฏิบัติที่ดีที่สุดคือการปรับปรุงประสบการณ์ของนักพัฒนาเสมอมา:

ต้องเขียนโปรแกรมเพื่อให้คนอ่าน และโดยบังเอิญเพื่อให้เครื่องทำงาน

Abelson & Sussman โครงสร้างและการตีความโปรแกรมคอมพิวเตอร์

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