開發 WordPress 插件時的經驗教訓

每個 WordPress 插件開發人員都在與難以維護的棘手問題和代碼作鬥爭。 當升級破壞我們的插件時，我們會在深夜為我們的用戶提供支持並撕毀我們的頭髮。 讓我告訴你如何使它更容易。

在本文中，我將分享我五年開發 WordPress 插件的經驗。 我寫的第一個插件是一個簡單的營銷插件。 它顯示了一個帶有 Google 搜索短語的號召性用語 (CTA) 按鈕。 從那時起，我又編寫了 11 個免費插件，並且我維護了幾乎所有的插件。 我已經為我的客戶編寫了大約 40 個插件，從非常小的插件到現在已經維護了一年多的插件。

良好的開發和支持會帶來更多的下載。 更多的下載意味著更多的錢和更好的聲譽。 本文將向您展示我學到的教訓和犯過的錯誤，以便您改進插件開發。

1. 解決問題

如果您的插件不能解決問題，則不會下載。 就這麼簡單。

使用 Advanced Cron Manager 插件（超過 8,000 次活動安裝）。 它可以幫助難以調試 cron 的 WordPress 用戶。 該插件是出於需要而編寫的——我需要一些東西來幫助自己。 我不需要推銷這個，因為人們已經需要它了。 它搔了他們的癢。

另一方面，有一個 Bug — fly on the screen 插件（70 多個活動安裝）。 它隨機模擬屏幕上的蒼蠅。 它並沒有真正解決問題，所以它不會有大量的觀眾。 不過，這是一個有趣的插件開發。

專注於一個問題。 當人們看不到他們的 SEO 表現不佳時，他們會安裝一個 SEO 插件。 當人們想要加速他們的網站時，他們會安裝一個緩存插件。 當人們找不到他們的問題的解決方案時，他們就會找到一個為他們編寫解決方案的開發人員。

正如 David Hehenberger 在他關於編寫成功插件的文章中所證明的那樣，需求是 WordPress 用戶決定是否安裝特定插件的關鍵因素。

如果您有機會解決某人的問題，請抓住機會。

2. 支持您的產品

“五分之三的美國人會嘗試新品牌或新公司以獲得更好的服務體驗。 十分之七的人表示他們願意在他們認為提供優質服務的公司上花更多的錢。”

— 尼基耶格爾

不要忽視你的支持。 不要把它當作必須的，而更像是一個機會。

高質量的支持對於您的插件發展至關重要。 即使是具有最佳代碼的插件也會獲得一些支持票。 使用您的插件的人越多，您獲得的門票就越多。 更好的用戶體驗會讓你獲得更少的票，但你永遠不會到達收件箱 0。

每次有人在支持論壇上發布消息時，我都會立即收到電子郵件通知，我會盡快回复。 它得到了回報。 由於支持，我獲得了絕大多數好評。 這是一個副作用：良好的支持通常會轉化為 5 星評價。

當您提供出色的支持時，人們開始信任您和您的產品。 插件是一種產品，即使它是完全免費和開源的。

良好的支持比每天寫一個簡短的答案更複雜。 當您的插件獲得關注時，您每天將獲得幾張門票。 如果您主動並在客戶提出問題之前回答他們的問題，則管理起來會容易得多。

以下是您可以採取的一些操作的列表：

• 在您的存儲庫中創建一個常見問題解答部分。
• 將“在您詢問之前”主題固定在您的支持論壇頂部，突出顯示故障排除提示和常見問題解答。
• 確保您的插件易於使用，並且用戶知道他們在安裝後應該做什麼。 用戶體驗很重要。
• 分析支持問題並解決痛點。 設立一個委員會，人們可以在其中投票選出他們想要的功能。
• 創建一個展示插件如何工作的視頻，並將其添加到 WordPress.org 存儲庫中插件的主頁。

您使用什麼軟件來支持您的產品並不重要。 WordPress.org 的官方支持論壇與電子郵件或您自己的支持系統一樣有效。 我使用 WordPress.org 的論壇獲取免費插件，使用我自己的系統獲取高級插件。

3. 不要使用 Composer

Composer 是包管理器軟件。 軟件包存儲庫託管在 packagist.org 上，您可以輕鬆地將它們下載到您的項目中。 它就像 PHP 的 NPM 或 Bower。 以 Composer 的方式管理第三方包是一種很好的做法，但不要在 WordPress 項目中使用它。

我知道，我丟了一顆炸彈。 讓我解釋。

Composer 是一款很棒的軟件。 我自己使用它，但不在公共 WordPress 項目中使用。 問題在於衝突。 WordPress 沒有任何全局包管理器，因此每個插件都必須加載自己的依賴項。 當兩個插件加載相同的依賴項時，會導致致命錯誤。

這個問題並沒有真正理想的解決方案，但 Composer 使情況變得更糟。 您可以手動將依賴項捆綁到源中，並始終檢查您是否可以安全地加載它。

Composer 與 WordPress 插件有關的問題仍未解決，並且在不久的將來不會有任何可行的解決方案來解決這個問題。 這個問題是多年前提出的，正如您在 WP Tavern 的文章中看到的那樣，許多開發人員都在嘗試解決它，但沒有任何運氣。

您可以做的最好的事情是確保條件和環境適合運行您的代碼。

4、合理支持PHP老版本

不支持非常舊的 PHP 版本，例如 5.2。 安全問題和維護不值得，而且您不會從這些舊版本中獲得更多安裝。

使用 PHP 5.6 作為最低要求，儘管官方支持將在 2018 年底之前停止。WordPress 本身需要 PHP 7.2。

有一種運動不鼓勵對舊 PHP 版本的支持。 Yoast 團隊發布了 Whip 庫，您可以將其包含在您的插件中，並向您的用戶顯示有關他們的 PHP 版本以及他們為什麼應該升級的重要信息。

告訴您的用戶您支持哪些版本，並確保他們的網站在您的插件安裝到過低版本後不會中斷。

5. 關注質量代碼

一開始編寫好的代碼很困難。 學習“SOLID”原則和設計模式並改變舊的編碼習慣需要時間。

曾經我花了三天時間在 WordPress 中顯示一個簡單的字符串，當時我決定使用更好的編碼實踐重寫我的一個插件。 知道它應該花費 30 分鐘，這令人沮喪。 改變我的心態很痛苦，但值得。

為什麼這麼難？ 因為你開始編寫一開始看起來有點矯枉過正而且不是很直觀的代碼。 我一直在問自己，“這真的需要嗎？” 例如，您必須將邏輯分成不同的類，並確保每個類負責單一的事情。 您還必須為翻譯、自定義帖子類型註冊、資產管理、表單處理程序等分離類。然後，您可以從簡單的小對像中組合出更大的結構。 這稱為依賴注入。 這與擁有所有代碼的“前端”和“管理”類非常不同。

另一個違反直覺的做法是將所有操作和過濾器保留在構造函數方法之外。 這樣，您在創建對象時不會調用任何操作，這對單元測試非常有幫助。 您還可以更好地控制執行哪些方法以及何時執行。 我希望我在編寫一個由構造函數方法中的操作引起的無限循環的項目之前知道這一點。 這些類型的錯誤很難追踪，也很難修復。 該項目必須重構。

以上只是一些示例，但您應該了解 SOLID 原則。 這些對任何系統和任何編碼語言都有效。

當您遵循所有最佳實踐時，您就會達到每個新功能都適合的地步。您無需調整任何內容或對現有代碼進行任何例外處理。 太奇妙了。 您的代碼不會變得更複雜，而是會變得更高級，而不會失去靈活性。

此外，正確格式化您的代碼，並確保團隊中的每個成員都遵循標準。 標準將使您的代碼可預測並且更易於閱讀和測試。 WordPress 有自己的標準，您可以在項目中實施。

6. 提前測試你的插件

我以艱難的方式吸取了這一教訓。 缺乏測試導致我發布了一個帶有致命錯誤的插件的新版本。 兩次。 兩次，我都獲得了 1 星評級，但我無法將其轉化為正面評價。

您可以手動或自動測試。 Travis CI 是與 GitHub 集成的持續測試產品。 我為我的 Notification 插件構建了一個非常簡單的測試套件，它只檢查插件是否可以在每個 PHP 版本上正確啟動。 這樣，我可以確定插件是沒有錯誤的，而且我不必太注意在每個環境中測試它。

每個自動化測試只需要幾分之一秒。 完成 100 個自動化測試大約需要 10 分鐘，而手動測試每個案例大約需要 2 分鐘。

您在預先測試插件上投入的時間越多，從長遠來看，它為您節省的時間就越多。

要開始自動化測試，您可以使用 WP-CLI \\`wp scaffold plugin-test\\` 命令，它會安裝您需要的所有配置。

7. 記錄你的工作

開發人員不喜歡編寫文檔是陳詞濫調。 這是開發過程中最無聊的部分，但有一點可以走很長的路。

編寫自記錄代碼。 注意變量、函數和類名。 不要製作任何復雜的結構，例如不易閱讀的級聯。

記錄代碼的另一種方法是使用“文檔塊”，它是每個文件、函數和類的註釋。 如果你寫了函數的工作原理和作用，那麼六個月後你需要調試它時會更容易理解。 WordPress 編碼標准通過強制您編寫文檔塊來涵蓋這一部分。

使用這兩種技術將節省您編寫文檔的時間，但並不是每個人都可以閱讀代碼文檔。

對於最終用戶，您必須撰寫高質量、簡短且易於閱讀的文章，解釋系統的工作原理和使用方法。 視頻更好； 許多人更喜歡看一個簡短的教程而不是閱讀一篇文章。 他們不會看代碼，所以讓他們的生活更輕鬆。 良好的文檔還可以減少支持票。

結論

這七項規則幫助我開發了優質產品，這些產品開始成為 BracketSpace 的核心業務。 我希望他們也能在您使用 WordPress 插件的過程中為您提供幫助。

在評論中讓我知道您的黃金開發規則是什麼，或者您是否發現上述任何一項特別有用。