使用現代 PHP 改進 WordPress 代碼

WordPress 誕生於 15 年前，由於它歷來保留了向後兼容性，其代碼的新版本無法充分利用新版本 PHP 提供的最新功能。 雖然 PHP 的最新版本是 7.3.2，但 WordPress 仍然提供最高到 PHP 5.2.4 的支持。

但那些日子很快就會過去！ WordPress 將升級其最低 PHP 版本支持，在 2019 年 4 月升級到 PHP 5.6，在 2019 年 12 月升級到 PHP 7（如果一切按計劃進行的話）。 然後，我們終於可以開始使用 PHP 的命令式編程功能，而不必擔心破壞我們客戶的網站。 歡呼！

因為 WordPress 十五年的功能代碼影響了開發人員使用 WordPress 構建的方式，所以我們的網站、主題和插件可能會充斥著不太理想的代碼，這些代碼可以很高興地接受升級。

本文由兩部分組成：

1. 最相關的新功能
   PHP 版本 5.3、5.4、5.5、5.6 和 7.0 中添加了更多功能（請注意，沒有 PHP 6），我們將探索最相關的功能。
2. 構建更好的軟件
   我們將仔細研究這些功能以及它們如何幫助我們構建更好的軟件。

讓我們從探索 PHP 的“新”特性開始。

類、OOP、SOLID 和設計模式

PHP 5 中添加了類和對象，因此 WordPress 已經使用了這些功能，但是，不是非常廣泛或全面： WordPress 中的編碼範例主要是函數式編程（通過調用沒有應用程序狀態的函數來執行計算）而不是對象面向編程（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 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 核心中消失。

命名空間允許在結構上組織代碼庫以避免在不同項目具有相同名稱時發生衝突——其方式類似於操作系統目錄，只要它們存儲在不同的目錄中，就允許具有相同名稱的不同文件。 命名空間對 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 標準推薦 PSR-4，應用程序可以使用 Composer 的自動加載機制來加載文件，從而降低複雜性並增加依賴項之間的無摩擦互操作性。 該約定規定將供應商名稱（例如公司名稱）作為頂部子名稱空間，可選地後跟包名稱，然後才跟一個內部結構，其中每個子名稱空間對應於具有相同名稱的目錄。 結果將驅動器中文件的物理位置與文件中定義的元素的命名空間一一對應。

性狀

特性已添加到 PHP 5.4，因此它們目前完全從 WordPress 核心中消失。

PHP 支持單一繼承，因此子類從一個父類派生，而不是從多個父類派生。 因此，不相互擴展的類不能通過類繼承重用代碼。 Traits 是一種能夠實現行為水平組合的機制，使得在不同類層次結構中的類之間重用代碼成為可能。

特徵類似於類，但是它不能單獨實例化。 相反，可以認為在 trait 中定義的代碼在編譯時被“複製並粘貼”到組合類中。

使用trait關鍵字定義特徵，之後可以通過use關鍵字將其導入任何類。 在下面的示例中，兩個完全不相關的類Person和Shop可以通過 trait 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 已經使用了這個功能，但是非常謹慎：核心總共包含不到十個接口！

接口允許創建指定必須實現哪些方法的代碼，但不必定義這些方法是如何實際實現的。 它們對於定義組件之間的契約很有用，這可以提高應用程序的模塊化和可維護性：實現接口的類可以是一個黑盒代碼，只要接口中函數的簽名不改變，代碼可以隨意升級而不會產生重大更改，這有助於防止技術債務的積累。 此外，它們可以通過允許將某些接口的實現交換到不同供應商的實現來幫助減少供應商鎖定。 因此，必須針對接口而不是實現對應用程序進行編碼（並通過依賴注入定義哪些是實際實現）。

接口是使用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 核心中消失。

閉包是一種實現匿名函數的機制，它有助於將全局命名空間與一次性（或很少使用）函數分開。 從技術上講，閉包是類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 已經能夠聲明接口和數組（它沒有：我幾乎沒有找到一個函數實例在核心中將數組聲明為參數，並且沒有接口），並且將很快就能聲明可調用對象（PHP 5.4 中添加）和標量類型：bool、float、int 和字符串（PHP 7.0 中添加）。 返回類型聲明被添加到 PHP 7.0。

參數類型聲明允許函數聲明參數必須是什麼特定類型。 驗證在調用時執行，如果參數的類型不是聲明的類型，則拋出異常。 返回類型聲明是相同的概念，但是，它們指定將從函數返回的值的類型。 類型聲明有助於使函數的意圖更易於理解，並避免接收或返回意外類型導致的運行時錯誤。

參數類型在參數變量名之前聲明，返回類型在參數之後聲明，前面是:

 function foo(boolean $bar): int { }

標量參數類型聲明有兩個選項：強制和嚴格。 在強制模式下，如果作為參數傳遞了錯誤的類型，它將被轉換為正確的類型。 例如，為期望字符串的參數提供整數的函數將獲得字符串類型的變量。 在嚴格模式下，僅接受具有確切聲明類型的變量。

強制模式是默認設置。 要啟用嚴格模式，我們必須添加與strict_types聲明一起使用的declare語句：

 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 添加了幾個新的運算符：Null 合併運算符 ( ?? ) 和 Spaceship 運算符 ( <=> )。

Null 合併運算符?? 是需要將三元與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 的關於從一個版本遷移到另一個版本的文檔來獲得本文未列出的其他新特性的列表。

接下來，我們將分析如何充分利用所有這些新功能，以及 Web 開發的最新趨勢，以生產出更好的軟件。

PHP 標準建議

PHP 標準建議是由一群來自流行框架和庫的 PHP 開發人員創建的，他們試圖建立約定，以便不同的項目可以更無縫地集成，不同的團隊可以更好地相互合作。 這些建議不是靜態的：現有的建議可能會被棄用，而新的建議可能會取代它們，新的建議會持續發布。

目前的建議如下：

在組件中思考和編碼

組件可以使用框架中的最佳功能，而不必局限於框架本身。 例如，Symfony 已作為一組可重用的 PHP 組件發布，可以獨立於 Symfony 框架安裝； Laravel 是另一個 PHP 框架，它利用了幾個 Symfony 組件，並發布了自己的一組可重用組件，可供任何 PHP 項目使用。

所有這些組件都發佈在 Packagist（一個公共 PHP 包的存儲庫）中，並且可以通過 Composer（一個非常流行的 PHP 依賴項管理器）輕鬆添加到任何 PHP 項目中。

WordPress 應該是這樣一個良性發展週期的一部分。 不幸的是，WordPress 核心本身不是使用組件構建的（幾乎完全沒有接口就證明了這一點），而且，它甚至沒有通過 Composer 安裝 WordPress 所需的composer.json文件。 這是因為 WordPress 社區尚未就 WordPress 是網站的依賴項（在這種情況下通過 Composer 安裝它是合理的）還是網站本身（在這種情況下，Composer 可能不是該工作的正確工具）達成一致意見.

在我看來，如果我們希望 WordPress 在未來 15 年內保持相關性（至少 WordPress 作為後端 CMS），那麼WordPress 必須被識別為站點的依賴項，並可以通過 Composer 進行安裝。 原因很簡單：在終端中只需一個命令，Composer 就可以從 Packagist 中發布的數千個包中聲明和安裝項目的依賴項，從而可以立即創建極其強大的 PHP 應用程序，開發者喜歡以這種方式工作。 如果 WordPress 不適應這種模式，它可能會失去開發社區的支持並被遺忘，就像 FTP 在引入基於 Git 的部署後失寵一樣。

我認為 Gutenberg 的發布已經證明 WordPress 是一個站點依賴項，而不是站點本身：Gutenberg 將 WordPress 視為無頭 CMS，並且也可以與其他後端系統一起運行，正如 Drupal Gutenberg 所舉例說明的那樣。 因此，Gutenberg 明確表示支持站點的 CMS 是可交換的，因此應將其視為依賴項。 此外，Gutenberg 本身打算基於通過 npm 發布的 JavaScript 組件（正如核心提交者 Adam Silverstein 所解釋的那樣），因此如果希望 WordPress 客戶端通過 npm 包管理器管理其 JavaScript 包，那麼為什麼不將此邏輯擴展到後端為了通過 Composer 管理 PHP 依賴項？

現在好消息：無需等待此問題得到解決，因為已經可以將 WordPress 視為站點的依賴項並通過 Composer 安裝它。 John P. Bloch 在 Git 中鏡像了 WordPress 核心，添加了一個 composer.json 文件，並在 Packagist 中發布，Roots 的 Bedrock 提供了一個安裝 WordPress 的包，該包具有自定義文件夾結構，支持現代開發工具和增強的安全性。 主題和插件也包括在內； 只要它們已列在 WordPress 主題和插件目錄中，它們就可以在 WordPress Packagist 下使用。

因此，創建 WordPress 代碼而不是考慮主題和插件，而是考慮組件是一個明智的選擇，通過 Packagist 使它們可供任何 PHP 項目使用，並且另外打包和發佈為主題和用於 WordPress 特定用途的插件。 如果組件需要與 WordPress API 交互，那麼這些 API 可以抽象為一個接口，如果需要，也可以為其他 CMS 實現。

添加模板引擎以改進視圖層

如果我們遵循在組件中思考和編碼的建議，將 WordPress 視為站點本身而不是站點本身的依賴項，那麼我們的項目就可以擺脫 WordPress 強加的界限，並從其他框架中引入思想和工具。

在服務器端呈現 HTML 內容就是一個很好的例子，它是通過普通的 PHP 模板完成的。 這個視圖層可以通過模板引擎 Twig（Symfony）和 Blade（Laravel）來增強，它們提供了非常簡潔的語法和強大的功能，使其優於普通的 PHP 模板。 特別是，Gutenberg 的動態塊可以很容易地從這些模板引擎中受益，因為它們在服務器端呈現塊的 HTML 的過程與 WordPress 的模板層次結構分離。

建築師一般用途的應用程序

對接口進行編碼並從組件的角度進行思考，使我們能夠為一般用途構建應用程序，並針對我們需要交付的特定用途對其進行定制，而不是僅針對我們擁有的每個項目的特定用途進行編碼。 儘管這種方法在短期內成本更高（它涉及額外的工作），但從長遠來看，如果只需定制一個通用應用程序就可以以較低的工作量交付額外的項目，它就會得到回報。

為了使這種方法有效，必須考慮以下因素：

避免固定依賴（盡可能）

jQuery 和 Bootstrap（或 Foundation，或<–在此處插入您最喜歡的庫–> ）在幾年前可能被認為是必備品，但是，它們在 vanilla JS 和更新的原生 CSS 功能面前逐漸失去優勢。 因此，五年前編寫的依賴於這些庫的通用項目現在可能不再適用。 因此，作為一般經驗法則，對第三方庫的固定依賴數量越少，從長遠來看，它就越是最新的。

功能的逐步增強

WordPress 是一個成熟的 CMS 系統，其中包括用戶管理，因此對用戶管理的支持是開箱即用的。 但是，並非每個 WordPress 站點都需要用戶管理。 因此，我們的應用程序應該考慮到這一點，並在每種情況下優化工作：在需要時支持用戶管理，但在不需要時不加載相應的資產。 這種方法也可以逐步發揮作用：假設客戶需要實現聯繫我們表單但沒有預算，因此我們使用功能有限的免費插件對其進行編碼，而另一個客戶有預算從商業插件產品購買許可證更好的功能。 然後，我們可以將我們的功能編碼為默認為非常基本的功能，並越來越多地使用系統中功能最強大的插件中的功能。

持續的代碼和文檔審查

通過定期查看我們之前編寫的代碼及其文檔，我們可以驗證它是否是最新的關於新的約定和技術，如果不是，則在技術債務變得過於昂貴而無法克服之前採取措施對其進行升級我們需要從頭開始重新編碼。

推薦閱讀：當心：可能使您的網站不安全的 PHP 和 WordPress 函數

嘗試盡量減少問題，但在問題發生時做好準備

沒有軟件是 100% 完美的：錯誤總是存在的，只是我們還沒有找到它們。 因此，我們需要確保一旦出現問題，它們很容易解決。

讓它變得簡單

複雜的軟件無法長期維護：不僅因為其他團隊成員可能不理解它，還因為編寫它的人可能在幾年後無法理解他/她自己的複雜代碼。 所以生產簡單的軟件必須是首要任務，因為只有簡單的軟件才能正確和快速。

編譯時失敗比運行時失敗好

如果一段代碼可以在編譯時或運行時驗證錯誤，那麼我們應該優先考慮編譯時解決方案，這樣錯誤就可以在開發階段和應用程序投入生產之前出現並得到處理。 例如， const和define都用於定義常量，然而， const在編譯時驗證， define在運行時驗證。 因此，只要有可能，使用const優於define 。

遵循此建議，可以通過將實際類作為參數而不是帶有類名的字符串傳遞來增強掛鉤包含在類中的 WordPress 函數。 在下面的例子中，如果類Foo被重命名，而第二個鉤子會產生編譯錯誤，第一個鉤子會在運行時失敗，因此第二個鉤子更好：

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

出於與上述相同的原因，我們應該避免使用全局變量（例如global $wpdb ）：這些變量不僅會污染全局上下文並且不容易跟踪它們的來源，而且如果它們被重命名，錯誤將在運行時生成。 作為一種解決方案，我們可以使用依賴注入容器來獲取所需對象的實例。

處理錯誤/異常

我們可以創建Exception對象的架構，以便應用程序可以根據每個特定問題做出適當的反應，盡可能從中恢復，或者在沒有時向用戶顯示有用的錯誤消息，並且通常為管理員解決問題。 並始終保護您的用戶免受白屏死機：所有未捕獲的Error和Exception都可以通過函數set_exception_handler攔截，以在屏幕上打印不可怕的錯誤消息。

採用構建工具

構建工具可以通過自動執行手動執行非常繁瑣的任務來節省大量時間。 WordPress 不提供與任何特定構建工具的集成，因此將這些集成到項目中的任務將完全落在開發人員身上。

有不同的工具可以實現不同的目的。 例如，有構建工具來執行壓縮和調整圖像大小、縮小 JS 和 CSS 文件以及將文件複製到目錄以生成發布的任務，例如 Webpack、Grunt 和 Gulp； 其他工具有助於創建項目的腳手架，這有助於為我們的主題或插件生成文件夾結構，例如 Yeoman。 事實上，有這麼多工具，瀏覽比較不同可用工具的文章將有助於找到最適合我們需求的工具。

但是，在某些情況下，沒有構建工具可以完全滿足我們項目的需求，因此我們可能需要編寫自己的構建工具作為項目本身的擴展。 例如，我這樣做是為了生成 service-worker.js 文件，以在 WordPress 中添加對 Service Worker 的支持。

結論

由於非常強調保持向後兼容性，甚至擴展到 PHP 5.2.4，WordPress 無法從 PHP 中添加的最新功能中受益，這一事實使得 WordPress 成為一個不太令人興奮的編碼平台在許多開發人員中。

幸運的是，這些陰霾的日子可能很快就會過去，WordPress 可能會再次成為一個閃亮而令人興奮的編碼平台：從 2019 年 12 月開始的 PHP 7.0+ 要求將提供大量 PHP 功能，使開發人員能夠生產更強大和性能更高的軟件。 在本文中，我們回顧了最重要的 PHP 新特性以及如何充分利用它們。

近期發布的 Gutenberg 可能是好時光即將到來的標誌：即使 Gutenberg 本身還沒有被社區完全接受，至少它表明了將最新技術（如 React 和 Webpack）納入核心的意願. 這一轉折讓我想：如果前端可以進行這樣的改造，為什麼不將其擴展到後端呢？ 一旦 WordPress 至少需要 PHP 7.0，升級到現代工具和方法的速度就會加快：儘管 npm 成為首選的 JavaScript 包管理器，為什麼不讓 Composer 成為官方的 PHP 依賴項管理器呢？ 如果塊是在前端構建站點的新單元，為什麼不使用 PHP 組件作為將功能合併到後端的單元呢？ 最後，如果 Gutenberg 將 WordPress 視為可交換的後端 CMS，為什麼不承認 WordPress 是站點依賴項而不是站點本身？ 我會把這些懸而未決的問題留給你思考和思考。