如何進行現代 WordPress 開發（第 1 部分）

已發表: 2022-03-11

WordPress 代碼庫一團糟已經不是什麼秘密了。 就我個人而言，每次經歷它，我只想蜷縮起來哭泣。 另一方面，WordPress 遠遠領先於競爭對手。 易於使用且功能強大的 CMS 是一項艱鉅的任務，而 WordPress 仍然很受歡迎，因為它提供了這一點。

那麼我們為什麼要關心 WordPress 核心中的代碼質量呢？ 它有效，對吧？

是的，它可以工作，而且這個有 15 年曆史的代碼庫不太可能被它的志願者維護者完全重構。 不幸的是，這意味著它也可以作為編碼“WordPress 方式”的示例，為許多開發人員不遵循最佳實踐和現代開發技術開脫。 如此多的 WordPress 插件和主題的代碼臭名昭著，盲目地遵循傳統做法只會繼續這種趨勢。

但是誰在乎仍然有效的糟糕代碼呢？ 好吧，沒有什麼是免費的，有人會為做得不好的工作買單。 謝天謝地，有了 WordPress 代碼庫本身，它的維護者付出了他們的時間。 但是使用您自己的代碼，支付費用的是您的客戶。

對於任何即使是中等複雜的系統，初始開發的成本與維護成本相比都是微不足道的，維護也意味著添加新功能。 聘請開發人員來修復設計和實施不佳的軟件的成本將比從一開始就正確開發軟件的成本高出數倍。

從長遠來看，廉價的解決方案總是最昂貴的。 或者他們在預算用完後被放棄。 當我們遵循經過驗證的軟件設計原則和實踐時，我們實際上可以節省客戶的資金。 這些方法不是炒作的時尚，也不是為了改變而改變。 這裡的智慧源於集體開發人員的經驗，遵循它確實有回報。

顯然，這不適用於真正簡單的任務，例如添加幾行 CSS 或幾個自定義帖子和重寫。 但無論如何，將幾個插件（或更常見的幾十個插件）拼湊在一起或製作一個由 Visual Composer 提供支持的網站都不是軟件工程。

這本身並不是一件壞事——一些解決方案如此簡單的事實就是 WordPress 如此受歡迎的原因。 但在本系列中，我將討論真正的WordPress 開發：編寫重要的 PHP、HTML、CSS 和 JavaScript 代碼。 我將從一般工作流程開始，然後在本文中關注 WordPress 前端開發。

現代 WordPress 開發工作流程

一般來說，質量代碼是：

  • 可讀。 很容易理解代碼的作用和原因。
  • 模塊化的。 目的明確的小代碼塊易於理解、開發和測試。
  • 可重複使用的。 重新使用已經開發的模塊來解決類似的問題可以顯著加快開發速度。
  • 可維護。 修改舊功能或引入新功能很容易。

主要結果——更低的開發成本和擁有成本——有許多附帶的好處，我不會在這裡討論。

相反，我將關注哪些開發技術和最佳實踐可以幫助您生成高質量的代碼。 讓我們從版本控制開始。

使用版本控制

這意味著使用 Git。 可悲的是，通過 FTP 進行生產的“牛仔編碼”幾乎仍然是一回事。 就在最近，我在一家位於英國的機構工作，他們的代碼庫中都有類似以下名稱的文件：

  • functions copy.php
  • functions copy 2.php
  • functions test.php
  • functions2.php
  • functions test2.php

使用 WordPress 網站時，您應該做的第一件事就是將其置於版本控制之下。 Tanking Servers 是對 WordPress 開發錯誤的有趣回顧。 使用 Git 來修改那些可能發生在每個人身上的類似事故是非常容易的。

你的代碼出錯了，整個網站都崩潰了？ git reset讓一切恢復原狀。 新版本更新破壞了一切？ git reset作為時間機器工作。 一些惡意代碼不知從何而來？ git status顯示任何新文件、已刪除文件或任何跟踪文件的更改。 然後你只需git checkout ，恢復原件。

小心暴露.git文件夾

好的，使用 Git 顯然很重要。 但是當你這樣做時，避免讓你的 Git 存儲庫被黑客入侵同樣重要。 當您公開.git文件夾並將您的憑據存儲在其中時，問題就來了。

標準的 WordPress 安裝完全存在於公共網絡文件夾中，並且.git文件夾也很可能在那裡。 顯然，不應將登錄憑據存儲在 Git 存儲庫中，但碰巧大多數存儲庫確實包含一些不應洩露到外部的敏感信息。

所以應該阻止對.git文件夾的公共訪問。 如果您使用的是 Apache，在.htaccess文件頂部添加下面的代碼段將阻止對.git文件夾和日誌文件的訪問。 日誌文件通常包含敏感信息，因此明智的做法是讓它們也不可用。 對於不同的 Web 服務器設置，請向您的 DevOps 專家尋求幫助。

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

使用單獨的環境

不要在實時站點上進行開發——這是停機和客戶不滿意的秘訣。 好的，但是你應該如何設置呢？

理想情況下，應該有三個開發環境，代碼總是朝著一個方向發展：本地→登台→生產。 這是一種經過驗證的避免碰撞的方法。 所有核心、插件和主題更新首先在本地完成，然後在 staging 上進行測試，最後部署到生產環境。

例如，特定於服務器的配置可以存儲在單獨的文件中。 您可以為每個本地和臨時環境創建一個wp-config-local.php 。 （不要忘記將它添加到您的.gitignore文件中！）然後將以下代碼段添加到wp-config.php ：

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

通常設置不同環境的最佳方法是使用環境變量。 如果您不熟悉這個概念，我建議您使用像 Roots 這樣的完整現代解決方案。

使用 WP-CLI

WordPress 命令行界面 (WP-CLI) 是用於管理 WordPress 安裝的非常有用的工具。 訪問 WP-CLI 意味著能夠運行幾乎任何 WordPress API 功能。 例如，您可以使用 WP-CLI 添加、刪除和編輯用戶及其密碼。 如果您剛剛繼承了一個站點並且所有者已將自己鎖定，則很有用。

另一個例子是使用 WP-CLI 可以輕而易舉地進行初始部署。 這些可以通過幾個命令來完成：

  • 下載核心、主題和插件
  • 在數據庫中搜索和替換
  • 添加管理員用戶

此外，這些動作可以腳本化和自動化。

使用高級部署選項

說到自動化，值得學習一些部署技術和流程，例如：

  • 持續集成/持續部署/交付 (CI/CD)
  • 碼頭工人
  • 自動化測試（包括前端回歸測試）

誠然，從不使用版本控製到處理 Docker 是一個巨大的飛躍，對於一個典型的單人 WordPress 項目來說可能是壓倒性的。 根據您的託管服務提供商，某些選項甚至可能無法實現。 但是對於團隊和大型項目來說，高級部署是必不可少的。

使用 Linting

但是，對於任何規模的項目，linting 對大多數開發人員來說都是一個福音。 Linting 意味著自動檢查您的代碼是否有錯誤。 PHPStorm 等功能齊全的 IDE 已經開箱即用。 然而，像 VSCode 或 Sublime Text 這樣更簡單的編輯器需要一個稱為 linter 的專用程序。 一種設置方法是將編輯器配置為在保存文件時運行 linter。

PHP_CodeSniffer 是 PHP 的事實上的 linter。 除了檢查語法錯誤之外，它還可以檢查您的代碼是否遵循 PSR-2 等樣式指南。 這大大簡化了以下編碼標準。

對於 JavaScript，ESLint 是一種流行的 linter。 它有一個廣泛的規則集，並支持所有 JavaScript 風格和框架的自定義配置。

這裡一個強大的用例是將 linting 合併到 CI/CD 構建管道中，以便在部署之前自動驗證所有代碼。

現代 WordPress 前端開發技術

現在為您的整個 WordPress 項目設置了適當的工作流程，讓我們深入研究前端的最佳實踐。

使用現代工具：Sass 和 ES6+

前端開發世界瞬息萬變，始終處於動態之中。 曾經我們認為 Sass 是編寫 CSS 的最佳工具——對於古騰堡之前的 WordPress 開發來說，它仍然是——但後來每個人都開始談論 CSS-in-JS 和样式化組件。

甚至 WordPress 也無法抗拒並採用了其中的一些新技術。 新的塊編輯器 Gutenberg 建立在 React 和 REST API 之上。

您絕對應該了解這些核心前端技術：

  • ES6+。 WordPress 文檔將其稱為 ESNext，甚至鼓勵使用它。
  • 薩斯。 由 WooCommerce 使用，如果您還沒有進入 CSS-in-JS 的領域，這是編寫 CSS 的最佳方式。
  • 網頁包。 甚至 WordPress 核心現在也使用 Webpack 和 Babel。

ES6 和 Sass 分別是現代 JavaScript 和 CSS，而 Webpack 是一個允許使用所有這些現代特性而無需擔心向後兼容性的工具。 Webpack 可以稱為前端應用程序編譯器，它生成文件以供在瀏覽器中使用。

從 jQuery 過渡到 Vue.js 或 React

WordPress 核心和幾乎所有 WordPress 插件都依賴於 jQuery，所以你不能停止使用它。 實際上，當您習慣於這樣做時，停止將它用於簡單的任務（例如隱藏幾個<div>或執行一次性 AJAX 請求）是沒有意義的。 無論如何都會加載 jQuery，而且它簡單易用。

複雜的應用程序是 jQuery 苦苦掙扎的地方：難以遵循的邏輯、回調地獄、全局變量和沒有 HTML 模板。 這顯然需要一種不同的方式來組織前端應用程序。

React 等現代前端庫使用面向對象編程 (OOP) 原則，並將前端應用程序架構組織成模塊化、可重用的組件。 組件包含特定元素的所有代碼、標記和“組件狀態”（變量）。 元素幾乎可以是任何東西：按鈕、輸入字段、用戶表單或顯示來自 WordPress REST API 後端的最新帖子的小部件。 組件可以包含其他組件，形成層次關係。

隨著當今網頁的複雜性，將應用程序組織成組件是構建任何復雜性的可維護、快速 Web 應用程序的一種行之有效的方法。 組件是高度可重用、隔離的，因此易於測試的“磚塊”，因此學習這個概念真的很值得。

目前有兩個流行的基於組件的庫：Vue.js 和 React。 React 將是一個顯而易見的選擇，因為它已經被 Gutenberg 使用。 然而，對於新接觸現代 JavaScript 的人來說，Vue.js 可能會更好。

React 通過使用 ES6 特性、類、專有 JSX 語法和 Webpack 構建管道直接將您帶入深淵。 學習曲線相當陡峭。

另一方面，Vue.js 對初學者更加友好，只需放入<script>標記即可使用。 Vue.js 使用純 JavaScript (ES5)、HTML 和 CSS。 新概念的引入要循序漸進。

在完成了幾個 Vue.js 項目之後，您將更好地準備深入研究 React。 並不是說它總是需要，但例如古騰堡開發確實需要它。

使用 WordPress REST API

WordPress 的 REST API 只是一個標準化接口，用於從 WordPress 遠程請求和修改數據。 它更像是一種軟件架構，而不是一種完全不同的編碼方式。 相同的舊 jQuery AJAX 片段可以使用稍有不同的參數。

最重要的好處？ 由於 WordPress REST API 標準化了後端和前端之間的通信，因此這是朝著代碼模塊化、可重用性和可讀性邁出的重要一步。 那些將 HTML 和 PHP 混合在一起的可怕模板以及一些混合在一起的 SQL 必須刪除。 一旦模板只是帶有作為參數傳遞的數據的佔位符的 HTML，那麼在 PHP 中或通過 REST API 將數據傳遞到前端應用程序之間沒有重大區別。

您可能還想查看 WPGraphQL。 它最終可能會或可能不會取代 WordPress REST API，但它正在迅速獲得關注。

學習古騰堡（客戶很快就會需要它）

Gutenberg 的最終目標是全站點定制，以及其他計劃。

這為 WordPress Core 的新模型奠定了基礎，該模型最終將影響平台的整個發布體驗。

GitHub 上的 WordPress Gutenberg 項目頁面

Gutenberg 確實受到了 WordPress 開發人員的強烈反對。 反對將其合併到 WordPress 核心中的一些論點是：

  • 很大一部分最終用戶不需要它，因此它應該是一個可選插件，而不是核心的一部分
  • 它破壞了一些網站
  • 它根本沒有準備好，可以使用更多的拋光和更少的錯誤

但是，對於使用 WordPress 作為博客平台的內容作者來說，Gutenberg 顯然提供了比舊編輯器更好的體驗。

只要需要，就會支持禁用古騰堡，是的。 但現在放鬆是一個明智的想法：當客戶接近您並要求進行 Gutenberg 開發時，您將做好準備。

是時候加快速度了：即使是“WordPress 方式”也在不斷發展

反對在 WordPress 開發中使用上述所有工具和技術的最常見論點是：“WordPress 方式”做事仍然有效，而且這種方式應該比所有這些新的閃亮的東西更好。

但是您現在已經看到，WordPress 核心開發人員非常了解所有最新發展。 不僅如此，由於其明顯的優勢，他們在核心的更新部分盡可能多地使用它們。 唯一阻礙我們的是沒有人會重構的遺留代碼。

一段時間以來，WordPress 和 WooCommerce 一直在遵循開發實現和使用新技術的“功能插件”的做法。 時機成熟時，這些插件會像 Gutenberg 那樣合併到核心中。 WooCommerce 也有自己的 React 項目。 WordPress REST API 也開始作為一個單獨的插件，現在是 WordPress 核心的一部分。

問題不在於我們是否應該學習新事物並在我的日常工作中使用它們，而是如何。 答案是“循序漸進”，一步一步。 要么學習新事物，要么以新的不同方式做你熟悉的事情。

例如，學習如何將 Webpack 與所有舊腳本一起使用。 Webpack 可以將您的新 ES6+ 代碼轉換為與舊瀏覽器兼容的“普通”JavaScript。 它還可以縮小腳本並將它們捆綁在一起。 這是一件新鮮事。 完畢？ 然後利用 ES6 特性重寫你的 JavaScript。 這是一種新的方式來做你所熟悉的事情。

結果：您將學習 Webpack 和 ES6。 作為專業人士，我們應該站出來，而不是退後。 永遠保持學習。 並在您這樣做時分享：Toptal 維護著一個 WordPress 開發最佳實踐列表，並歡迎社區對其做出貢獻。

在我們系列的第 2 部分中，我們將深入探討現代 WordPress 後端開發的 PHP 部分。