ปรับปรุงโค้ด WordPress ด้วย PHP สมัยใหม่

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

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

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

บทความนี้ประกอบด้วยสองส่วน:

1. คุณสมบัติใหม่ที่เกี่ยวข้องมากที่สุด
   มีการเพิ่มคุณสมบัติเพิ่มเติมใน PHP เวอร์ชัน 5.3, 5.4, 5.5, 5.6 และ 7.0 (โปรดสังเกตว่าไม่มี PHP 6) และเราจะสำรวจคุณสมบัติที่เกี่ยวข้องมากที่สุด
2. การสร้างซอฟต์แวร์ที่ดีขึ้น
   เราจะพิจารณาอย่างละเอียดยิ่งขึ้นเกี่ยวกับคุณลักษณะเหล่านี้และวิธีที่คุณลักษณะเหล่านี้สามารถช่วยเราสร้างซอฟต์แวร์ที่ดีขึ้นได้

เริ่มต้นด้วยการสำรวจคุณสมบัติ "ใหม่" ของ PHP

คลาส, OOP, SOLID และรูปแบบการออกแบบ

มีการเพิ่มคลาสและอ็อบเจ็กต์ใน PHP 5 ดังนั้น WordPress จึงใช้ประโยชน์จากคุณสมบัติเหล่านี้แล้ว แต่ไม่ครอบคลุมหรือครอบคลุมมากนัก: กระบวนทัศน์ของการเข้ารหัสใน WordPress ส่วนใหญ่เป็นการเขียนโปรแกรมเชิงฟังก์ชัน (ดำเนินการคำนวณโดยการเรียกใช้ฟังก์ชันที่ไม่มีสถานะแอปพลิเคชัน) แทนที่จะเป็นอ็อบเจ็กต์ -Oriented Programming (OOP) (ดำเนินการคำนวณโดยจัดการสถานะของอ็อบเจ็กต์) ดังนั้นฉันจึงอธิบายคลาสและอ็อบเจ็กต์และวิธีใช้งานผ่าน OOP

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

คลาสมีคุณสมบัติและฟังก์ชัน ซึ่งสามารถมองเห็นได้โดยใช้ private (เข้าถึงได้จากภายในคลาสที่กำหนดเท่านั้น) protected (เข้าถึงได้จากภายในคลาสที่กำหนด บรรพบุรุษ และคลาสที่สืบทอด) และ public (เข้าถึงได้จากทุกที่) จากภายในฟังก์ชัน เราสามารถเข้าถึงคุณสมบัติของคลาสโดยเติมชื่อด้วย $this-> :

 class Person { protected $name; public function __construct($name) { $this->name = $name; } public function getIntroduction() { return sprintf( __('My name is %s'), $this->name ); } }

คลาสถูกสร้างอินสแตนซ์เป็นอ็อบเจ็กต์ผ่านคีย์เวิร์ด new หลังจากนั้นเราสามารถเข้าถึงคุณสมบัติและฟังก์ชันของคลาสผ่าน -> :

 $person = new Person('Pedro'); echo $person->getIntroduction(); // This prints "My name is Pedro"

คลาสที่สืบทอดมาสามารถแทนที่ฟังก์ชัน public และฟังก์ชันที่ protected จากคลาสบรรพบุรุษของมัน และเข้าถึงฟังก์ชันบรรพบุรุษได้ด้วยการเติม parent:: :

 class WorkerPerson extends Person { protected $occupation; public function __construct($name, $occupation) { parent::__construct($name); $this->occupation = $occupation; } public function getIntroduction() { return sprintf( __('%s and my occupation is %s'), parent::getIntroduction(), $this->occupation ); } } $worker = new WorkerPerson('Pedro', 'web development'); echo $worker->getIntroduction(); // This prints "My name is Pedro and my occupation is web development"

เมธอดสามารถสร้าง abstract ได้ หมายความว่าต้องดำเนินการโดยคลาสที่สืบทอด คลาสที่มีเมธอด abstract จะต้องทำให้ abstract ด้วยตัวมันเอง หมายความว่ามันไม่สามารถสร้างอินสแตนซ์ได้ เฉพาะคลาสที่ใช้เมธอด abstract เท่านั้นที่สามารถยกตัวอย่างได้:

 abstract class Person { abstract public function getName(); public function getIntroduction() { return sprintf( __('My name is %s'), $this->getName() ); } } // Person cannot be instantiated class Manuel extends Person { public function getName() { return 'Manuel'; } } // Manuel can be instantiated $manuel = new Manuel();

คลาสยังสามารถกำหนดเมธอดและคุณสมบัติส static ซึ่งอยู่ภายใต้คลาสเอง และไม่อยู่ภายใต้อินสแตนซ์ของคลาสเป็นอ็อบเจ็กต์ สิ่งเหล่านี้เข้าถึงได้ผ่าน self:: จากภายในคลาส และผ่านชื่อของคลาส + :: จากภายนอก:

 class Factory { protected static $instances = []; public static function registerInstance($handle, $instance) { self::$instances[$handle] = $instance; } public static function getInstance($handle) { return self::$instances[$handle]; } } $engine = Factory::getInstance('Engine');

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

เนมสเปซ

มีการเพิ่มเนมสเปซใน PHP 5.3 ดังนั้นจึงขาดหายไปจากแกนหลักของ WordPress ทั้งหมด

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

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

เนมสเปซถูกกำหนดโดยใช้ namespace คำหลัก (วางไว้บนบรรทัดทันทีหลังจากเปิด <?php ) และสามารถขยายได้หลายระดับหรือเนมสเปซย่อย (คล้ายกับการมีไดเร็กทอรีย่อยหลายแห่งที่วางไฟล์) ซึ่งคั่นด้วย \ :

 <?php namespace CoolSoft\ImageResizer\Controllers; class ImageUpload { }

ในการเข้าถึงคลาสข้างต้น เราต้องมีคุณสมบัติครบถ้วนชื่อรวมถึงเนมสเปซ (และเริ่มต้นด้วย \ ):

 $imageUpload = new \CoolSoft\ImageResizer\Controllers\ImageUpload();

หรือเรายังสามารถนำเข้าคลาสในบริบทปัจจุบัน หลังจากนั้นเราสามารถอ้างอิงคลาสโดยใช้ชื่อโดยตรง:

 use CoolSoft\ImageResizer\Controllers\ImageUpload; $imageUpload = new ImageUpload();

การตั้งชื่อเนมสเปซตามแบบแผนที่กำหนดไว้ ทำให้เราได้รับประโยชน์เพิ่มเติม ตัวอย่างเช่น โดยการปฏิบัติตามมาตรฐาน PHP Standards Recommendation PSR-4 แอปพลิเคชันสามารถใช้กลไกการโหลดอัตโนมัติของ Composer ในการโหลดไฟล์ ซึ่งจะช่วยลดความซับซ้อนและเพิ่มความสามารถในการทำงานร่วมกันระหว่างการอ้างอิง ข้อตกลงนี้กำหนดขึ้นเพื่อรวมชื่อผู้ขาย (เช่น ชื่อบริษัท) เป็นเนมสเปซย่อยด้านบน ตามด้วยชื่อแพ็คเกจ และตามด้วยโครงสร้างภายในซึ่งแต่ละเนมสเปซย่อยสอดคล้องกับไดเร็กทอรีที่มีชื่อเดียวกัน ผลลัพธ์จะจับคู่ตำแหน่งทางกายภาพของไฟล์ในไดรฟ์ 1 ต่อ 1 โดยมีเนมสเปซขององค์ประกอบที่กำหนดไว้ในไฟล์

ลักษณะนิสัย

คุณลักษณะถูกเพิ่มเข้ามาใน PHP 5.4 ดังนั้นจึงขาดหายไปจากแกนหลักของ WordPress

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

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

ลักษณะถูกกำหนดโดยใช้คีย์เวิร์ด trait หลังจากนั้นสามารถอิมพอร์ตไปยังคลาสใดๆ ได้โดย use คีย์เวิร์ด use ในตัวอย่างด้านล่าง คลาสสองคลาสที่ไม่เกี่ยวข้องกันอย่างสมบูรณ์ Person และ Shop สามารถใช้รหัสเดียวกันซ้ำได้ผ่านคุณสมบัติ Addressable :

 trait Addressable { protected $address; public function getAddress() { return $this->address; } public function setAddress($address) { $this->address = $address; } } class Person { use Addressable; } class Shop { use Addressable; } $person = new Person('Juan Carlos'); $person->setAddress('Obelisco, Buenos Aires');

คลาสยังสามารถเขียนลักษณะได้มากกว่าหนึ่งลักษณะ:

 trait Exportable { public class exportToCSV($filename) { // Iterate all properties and export them to a CSV file } } class Person { use Addressable, Exportable; }

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

อินเทอร์เฟซ

อินเทอร์เฟซถูกเพิ่มเข้ามาใน PHP 5 ดังนั้น WordPress ได้ใช้ประโยชน์จากคุณลักษณะนี้แล้ว อย่างไรก็ตาม ในจำนวนที่จำกัดมาก: แกนหลักมีอินเทอร์เฟซทั้งหมดน้อยกว่า 10 อินเทอร์เฟซ!

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

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

 interface FileStorage { function save($filename, $contents); function readContents($filename); }

คลาสกำหนดว่าจะใช้อินเทอร์เฟซผ่านคำสำคัญที่ implements :

 class LocalDriveFileStorage implements FileStorage { function save($filename, $contents) { // Implement logic } function readContents($filename) { // Implement logic } }

คลาสสามารถใช้อินเตอร์เฟสได้มากกว่าหนึ่งอินเตอร์เฟส โดยแยกด้วย , :

 interface AWSService { function getRegion(); } class S3FileStorage implements FileStorage, AWSService { function save($filename, $contents) { // Implement logic } function readContents($filename) { // Implement logic } function getRegion() { return 'us-east-1'; } }

เนื่องจากอินเทอร์เฟซประกาศเจตนารมณ์ของสิ่งที่องค์ประกอบควรทำ การตั้งชื่ออินเทอร์เฟซอย่างเหมาะสมจึงเป็นสิ่งสำคัญอย่างยิ่ง

ปิด

เพิ่มการปิดใน PHP 5.3 ดังนั้นจึงขาดหายไปจากแกนหลักของ WordPress

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

ก่อนปิด เมื่อใดก็ตามที่ส่งผ่านฟังก์ชันเป็นอาร์กิวเมนต์ไปยังฟังก์ชันอื่น เราต้องกำหนดฟังก์ชันล่วงหน้าและส่งชื่อเป็นอาร์กิวเมนต์:

 function duplicate($price) { return $price*2; } $touristPrices = array_map('duplicate', $localPrices);

ด้วยการปิด ฟังก์ชันที่ไม่ระบุชื่อ (เช่น ไม่มีชื่อ) สามารถส่งผ่านโดยตรงเป็นพารามิเตอร์ได้แล้ว:

 $touristPrices = array_map(function($price) { return $price*2; }, $localPrices);

การปิดสามารถนำเข้าตัวแปรไปยังบริบทโดย use คำสำคัญ:

 $factor = 2; $touristPrices = array_map(function($price) use($factor) { return $price*$factor; }, $localPrices);

เครื่องกำเนิดไฟฟ้า

เครื่องกำเนิดไฟฟ้าถูกเพิ่มเข้ามาใน PHP 5.5 ดังนั้นจึงขาดหายไปจากแกนหลักของ WordPress ทั้งหมด

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

 function xrange($start, $limit, $step = 1) { for ($i = $start; $i <= $limit; $i += $step) { yield $i; } } foreach (xrange(1, 9, 2) as $number) { echo "$number "; } // This prints: 1 3 5 7 9

คำประกาศประเภทอาร์กิวเมนต์และส่งคืน

การประกาศประเภทอาร์กิวเมนต์ที่แตกต่างกันถูกนำมาใช้ในเวอร์ชันต่างๆ ของ PHP: WordPress สามารถประกาศอินเทอร์เฟซและอาร์เรย์ได้แล้ว (ซึ่งไม่เป็นเช่นนั้น: ฉันแทบไม่พบอินสแตนซ์ของฟังก์ชันที่ประกาศอาร์เรย์เป็นพารามิเตอร์ในคอร์ และไม่มีอินเทอร์เฟซ) และจะ ในไม่ช้าจะสามารถประกาศ callables (เพิ่มใน PHP 5.4) และประเภทสเกลาร์: bool, float, int และ string (เพิ่มใน PHP 7.0) มีการเพิ่มการประกาศประเภทการส่งคืนใน PHP 7.0

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

ประเภทอาร์กิวเมนต์ถูกประกาศก่อนชื่อตัวแปรอาร์กิวเมนต์ และประเภทการส่งคืนถูกประกาศหลังอาร์กิวเมนต์ นำหน้าด้วย : :

 function foo(boolean $bar): int { }

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

โหมดบีบบังคับเป็นค่าเริ่มต้น ในการเปิดใช้งานโหมดเข้มงวด เราต้องเพิ่มคำสั่ง declare ที่ใช้กับการประกาศที่ strict_types :

 declare(strict_types=1); function foo(boolean $bar) { }

ไวยากรณ์และตัวดำเนินการใหม่

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

 function sum(...$numbers) { $sum = 0; foreach ($numbers as $number) { $sum += $number; } return $sum; }

เริ่มต้นจาก PHP 5.6 ค่าคงที่สามารถเกี่ยวข้องกับนิพจน์สเกลาร์ที่เกี่ยวข้องกับตัวอักษรตัวเลขและสตริงแทนที่จะเป็นเพียงค่าคงที่และอาร์เรย์:

 const SUM = 37 + 2; // A scalar expression const LETTERS = ['a', 'b', 'c']; // An array

เริ่มต้นจาก PHP 7.0 อาร์เรย์ยังสามารถกำหนดได้โดยใช้ define :

 define('LETTERS', ['a', 'b', 'c']);

PHP 7.0 เพิ่มตัวดำเนินการใหม่สองสามตัว: ตัวดำเนินการรวมศูนย์ ( ?? ) และตัวดำเนินการ Spaceship ( <=> )

โอเปอเรเตอร์การรวมศูนย์ ?? เป็นน้ำตาลประโยคสำหรับกรณีทั่วไปที่ต้องการใช้ ternary ร่วมกับ isset() จะส่งกลับตัวถูกดำเนินการแรกหากมีอยู่และไม่ใช่ NULL มิฉะนั้น จะส่งกลับตัวถูกดำเนินการที่สอง

 $username = $_GET['user'] ?? 'nobody'; // This is equivalent to: // $username = isset($_GET['user']) ? $_GET['user'] : 'nobody';

ตัวดำเนินการ Spaceship <=> ใช้สำหรับเปรียบเทียบนิพจน์สองนิพจน์ โดยคืนค่า -1, 0 หรือ 1 เมื่อตัวถูกดำเนินการแรกมีค่าน้อยกว่า เท่ากับ หรือมากกว่าตัวถูกดำเนินการที่สองตามลำดับ

 echo 1 <=> 2; // returns -1 echo 1 <=> 1; // returns 0 echo 2 <=> 1; // returns 1

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

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

คำแนะนำมาตรฐาน PHP

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

คำแนะนำปัจจุบันมีดังต่อไปนี้:

คิดและเขียนโค้ดในส่วนประกอบ

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

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

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

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

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

ข่าวดี: ไม่จำเป็นต้องรอให้ปัญหานี้ได้รับการแก้ไข เนื่องจากมีความเป็นไปได้อยู่แล้วที่จะปฏิบัติต่อ WordPress เป็นการพึ่งพาไซต์และติดตั้งผ่าน Composer John P. Bloch ได้ทำมิเรอร์ WordPress core ใน Git เพิ่มไฟล์ composer.json และเผยแพร่ใน Packagist และ Roots 'Bedrock จัดเตรียมแพ็คเกจสำหรับติดตั้ง WordPress ด้วยโครงสร้างโฟลเดอร์ที่กำหนดเองพร้อมรองรับเครื่องมือการพัฒนาที่ทันสมัยและความปลอดภัยขั้นสูง และครอบคลุมถึงธีมและปลั๊กอินด้วย ตราบใดที่มีอยู่ในไดเรกทอรีธีมและปลั๊กอินของ WordPress พวกเขาจะอยู่ภายใต้ WordPress Packagist

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

การเพิ่มเครื่องมือเทมเพลตเพื่อปรับปรุง View Layer

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

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

สถาปนิก แอปพลิเคชันสำหรับการใช้งานทั่วไป

การเข้ารหัสเทียบกับอินเทอร์เฟซและการคิดในแง่ของส่วนประกอบช่วยให้เราสามารถออกแบบแอปพลิเคชันสำหรับการใช้งานทั่วไปและปรับแต่งสำหรับการใช้งานเฉพาะที่เราจำเป็นต้องนำเสนอ แทนที่จะเขียนโค้ดเฉพาะสำหรับการใช้งานเฉพาะสำหรับแต่ละโครงการที่เรามี แม้ว่าวิธีการนี้จะมีราคาแพงกว่าในระยะสั้น (เกี่ยวข้องกับงานพิเศษ) แต่ก็ให้ผลตอบแทนในระยะยาวเมื่อโครงการเพิ่มเติมสามารถส่งมอบได้โดยใช้ความพยายามน้อยลงจากการปรับแต่งแอปพลิเคชันที่ใช้งานทั่วไป

เพื่อให้แนวทางนี้มีประสิทธิภาพต้องคำนึงถึงข้อควรพิจารณาต่อไปนี้:

หลีกเลี่ยงการพึ่งพาอาศัยกัน (เท่าที่เป็นไปได้)

jQuery และ Bootstrap (หรือ Foundation หรือ <–insert your favorite library here–> ) อาจได้รับการพิจารณาว่าต้องมีเมื่อสองสามปีก่อน อย่างไรก็ตาม พวกมันสูญเสียพื้นฐานจาก vanilla JS และฟีเจอร์ CSS ดั้งเดิมที่ใหม่กว่า ดังนั้น โครงการใช้งานทั่วไปที่เขียนขึ้นเมื่อ 5 ปีที่แล้วซึ่งอาศัยห้องสมุดเหล่านี้อาจไม่เหมาะในปัจจุบันอีกต่อไป ดังนั้น ตามหลักการทั่วไป ยิ่งจำนวนการพึ่งพาคงที่ในไลบรารีของบุคคลที่สามน้อยลงเท่าใด ไลบรารีของบุคคลที่สามก็จะมีความทันสมัยมากขึ้นเท่านั้นที่จะพิสูจน์ได้ในระยะยาว

การเพิ่มประสิทธิภาพการทำงานแบบก้าวหน้า

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

การตรวจสอบรหัสและเอกสารอย่างต่อเนื่อง

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

การอ่านที่แนะนำ : ระวังให้ดี: ฟังก์ชัน PHP และ WordPress ที่สามารถทำให้ไซต์ของคุณไม่ปลอดภัย

พยายามลดปัญหาแต่เตรียมพร้อมเมื่อเกิดขึ้น

ไม่มีซอฟต์แวร์ใดที่สมบูรณ์แบบ 100% ข้อบกพร่องมีอยู่เสมอ เราแค่ยังไม่พบข้อบกพร่องเหล่านั้น ดังนั้น เราต้องตรวจสอบให้แน่ใจว่าเมื่อเกิดปัญหาขึ้นแล้ว พวกเขาจะแก้ไขได้ง่าย

ทำให้ง่าย

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

เวลาคอมไพล์ล้มเหลวยังดีกว่ารันไทม์

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

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

 class Foo { public static function bar() { } } add_action('init', ['Foo', 'bar']); // Not so good add_action('init', [Foo::class, 'bar']); // Much better

ด้วยเหตุผลเดียวกันกับข้างต้น เราควรหลีกเลี่ยงการใช้ตัวแปรโกลบอล (เช่น global $wpdb ): สิ่งเหล่านี้ไม่เพียงแต่สร้างมลพิษให้กับบริบทส่วนกลางเท่านั้น และไม่ใช่เรื่องง่ายที่จะติดตามว่ามาจากที่ใด หากมีการเปลี่ยนชื่อ ข้อผิดพลาดจะ ถูกผลิตบนรันไทม์ ในการแก้ปัญหา เราสามารถใช้ Dependency Injection Container เพื่อรับอินสแตนซ์ของอ็อบเจ็กต์ที่ต้องการ

การจัดการกับข้อผิดพลาด/ข้อยกเว้น

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

นำเครื่องมือสร้าง

เครื่องมือสร้างสามารถประหยัดเวลาได้มากด้วยการทำงานอัตโนมัติซึ่งน่าเบื่อมากในการดำเนินการด้วยตนเอง WordPress ไม่ได้เสนอการผสานรวมกับเครื่องมือสร้างใด ๆ ดังนั้นงานในการรวมสิ่งเหล่านี้เข้ากับโครงการจะตกอยู่ที่ผู้พัฒนาทั้งหมด

มีเครื่องมือที่แตกต่างกันสำหรับการบรรลุวัตถุประสงค์ที่แตกต่างกัน ตัวอย่างเช่น มีเครื่องมือสร้างสำหรับดำเนินการบีบอัดและปรับขนาดรูปภาพ ลดขนาดไฟล์ JS และ CSS และคัดลอกไฟล์ไปยังไดเร็กทอรีสำหรับการสร้างรีลีส เช่น Webpack, Grunt และ Gulp เครื่องมืออื่นๆ ช่วยสร้างโครงนั่งร้านของโปรเจ็กต์ ซึ่งเป็นประโยชน์สำหรับการสร้างโครงสร้างโฟลเดอร์สำหรับธีมหรือปลั๊กอินของเรา เช่น Yeoman ด้วยเครื่องมือที่มีอยู่มากมาย การเรียกดูบทความที่เปรียบเทียบเครื่องมือต่างๆ ที่มีอยู่จะช่วยค้นหาเครื่องมือที่เหมาะสมที่สุดสำหรับความต้องการของเรา

ในบางกรณี ไม่มีเครื่องมือสร้างที่สามารถบรรลุสิ่งที่โครงการต้องการได้ ดังนั้นเราอาจจำเป็นต้องเขียนโค้ดเครื่องมือสร้างของเราเองเป็นส่วนขยายของโครงการเอง ตัวอย่างเช่น ฉันได้ทำสิ่งนี้เพื่อสร้างไฟล์ service-worker.js เพื่อเพิ่มการรองรับ Service Workers ใน WordPress

บทสรุป

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

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

การเปิดตัว Gutenberg ครั้งล่าสุดอาจเป็นสัญญาณของช่วงเวลาดีๆ ที่จะมาถึง แม้ว่า Gutenberg เองจะไม่ได้รับการยอมรับจากชุมชนอย่างเต็มที่ อย่างน้อยก็แสดงให้เห็นถึงความเต็มใจที่จะรวมเทคโนโลยีล่าสุด (เช่น React และ Webpack) เข้าไว้ในแกนหลัก . เหตุการณ์ที่พลิกผันนี้ทำให้ฉันสงสัยว่า: หากส่วนหน้าสามารถปรับปรุงได้ ทำไมไม่ขยายไปยังส่วนหลัง เมื่อ WordPress ต้องการอย่างน้อย PHP 7.0 การอัพเกรดเป็นเครื่องมือและวิธีการที่ทันสมัยสามารถเร่งความเร็วได้: ตราบใดที่ npm กลายเป็นตัวจัดการแพ็คเกจ JavaScript ที่เลือก ทำไมไม่ทำให้ Composer กลายเป็นผู้จัดการการพึ่งพา PHP อย่างเป็นทางการล่ะ หากบล็อกเป็นหน่วยใหม่สำหรับการสร้างไซต์ในส่วนหน้า ทำไมไม่ใช้ส่วนประกอบ PHP เป็นหน่วยสำหรับการรวมฟังก์ชันการทำงานเข้ากับแบ็กเอนด์ และสุดท้าย หาก Gutenberg ถือว่า WordPress เป็น backend CMS ที่สับเปลี่ยนได้ เหตุใดจึงไม่ทราบว่า WordPress เป็นการพึ่งพาเว็บไซต์และไม่ใช่ตัวเว็บไซต์เอง ฉันจะทิ้งคำถามเปิดไว้ให้คุณไตร่ตรองและไตร่ตรอง