高級 WordPress 開發人員犯的 12 個最嚴重的錯誤

已發表: 2022-03-11

WordPress 是一種非常流行的快速啟動和運行網站的方式。 然而，在匆忙中，許多開發人員最終做出了可怕的決定。 一些錯誤，例如將WP_DEBUG設置為true可能很容易犯。 其他的，比如將你所有的 JavaScript 集中到一個文件中，就像懶惰的工程師一樣常見。 無論您犯了哪個錯誤，請繼續閱讀以找出新老開發人員所犯的 12 個最常見的 WordPress 錯誤。 如果您發現自己犯了這些錯誤之一，請不要絕望。 每個錯誤都是一次學習的機會。

WordPress 開發人員犯的主要錯誤

1. 將 WordPress 主題 JavaScript 代碼放入一個主文件

有一次，在為客戶的網站進行頁面速度優化時，我注意到他們使用了一個高級主題，其中包含他們正在使用的所有庫，包括自定義代碼，在一個名為main.js 、 theme.js或custom.js的文件中. 這種做法是不好的，原因如下：

  1. 該文件隨著時間的推移會變得非常大，因為正在積極開發的主題會增加功能，有時您會看到大至 1 MB 的文件。 即使某些頁面只需要文件中 10% 的代碼，該文件也會在站點範圍內加載。 這將使頁面下載時間更長，渲染速度更慢，特別是如果它在頁面的 head 部分呈現阻塞代碼。
  2. 它使管理文件中的代碼更加困難，因為您不能使用諸如wp_dequeue_script()之類的函數來卸載某些頁面中的某些代碼以提高頁面速度或防止與其他 JavaScript 代碼發生衝突由活動插件之一加載。 當然，該文件可以拆分為多個文件並在 WordPress 中排隊，但如果稍後網站管理員對主題的main.js文件執行更新，則整個過程必須重新開始。

2. 使用對變量、函數、常量或類來說太常見的名稱

在開發插件時，最好使用一種命名約定，以防止代碼衝突，以防有其他插件使用相同的名稱。 這就是為什麼許多開發人員在他們的變量和函數名稱前加上一些獨特的和與插件本身相關的東西。 除了消除代碼衝突之外，當您啟用大量插件時，它還可以讓您更容易找到。

另一方面，有些開發人員更喜歡使用 PHP 命名空間來封裝項目，並解決庫和應用程序的作者在創建類或函數等可重用代碼元素時遇到的兩個問題：

  1. 他們創建的代碼與內部 PHP 或第三方、類、函數或常量之間的名稱衝突
  2. 能夠為Extra_Long_Names起別名（或縮短），旨在解決第一個問題或提高源代碼的可讀性。 這是我最喜歡的一個，因為我經常開發包含大量代碼的主題或插件。 有了這個，我可以輕鬆地閱讀和管理代碼，而不必擔心有長的唯一名稱。

我建議在使用命名空間之前對它們有一個很好的了解，因為它們經常會以錯誤的方式使用。

根據您將參與的項目，您可能必須堅持現有的編碼風格，除非您的工作大部分與現有的編碼風格分開。 如果您必須擴展已經遵循 WordPress 的 PHP 編碼標準的現有插件或主題，那麼最好堅持使用它們以保持一致的風格，從而使代碼變得乾淨且易於閱讀。 請注意，有些規則是普遍應用的，以提高性能，而忽略編碼風格。 例如，如果您不評估字符串中的任何內容，最好使用單引號（而不是雙引號）。 此外，代碼必須縮進才能被閱讀，特別是如果它有嵌套代碼（例如， IF s 中的IF s，嵌套FOREACH s 和FOR s）。

3. 沒有利用現有的 WordPress 核心功能發揮其真正潛力

由於 WordPress 帶有一套定期更新的庫，可以在我們的插件和主題中調用，因此最好盡可能多地利用現有的核心功能。 我已經看到 WordPress 主題和插件在其資產目錄中有文件，而這些文件已經在 WordPress 核心文件中（例如，jQuery 或 Color Picker）。 除了包會變得更大並且通過網絡加載需要更長的時間之外，您還必須確保定期更新所有第三方庫，這只是另一件需要注意的事情。

利用 WordPress 已經提供的功能，因為庫已經由 WordPress 開發核心團隊更新，您可以擁有一個輕量級且更易於維護的項目。 通過定期進行 WordPress 更新，您可以獲得更多功能（無論是插件、主題還是 WordPress 核心本身，因為它的儀表板一直在改進）並在舊代碼版本中發現漏洞時使網站更加安全。

4. 不能通過操作和過濾器使插件或主題易於更改

直接編輯 WordPress 插件或主題不是一個好主意，當然，除非您直接參與該軟件包的開發並為其代碼做出貢獻。 如果對插件或主題執行自動更新，則對包的任何直接更改都將丟失，您將不得不重新編輯文件。

這就是為什麼使用動作和過濾器以及創建子主題（擴展父主題）是修改主題的最有效方法，因為您可以在不編輯父主題或插件本身的情況下更改現有功能。 此外，如果您在 WordPress.org 上提供免費下載的插件，並且稍後您想創建一個依賴於父插件的高級擴展，那麼您應該以這樣的方式開發免費插件：易於擴展和添加高級擴展。

5. 使用WP_DEBUG設置為false進行開發

默認情況下， WP_DEBUG常量設置為“false”以避免打印任何 PHP 錯誤、警告和通知。 在實時環境中，這是一個推薦的選擇，因為它可以將私有服務器路徑和腳本隱藏在公眾視野之外，這對於安全原因來說非常有用。 但是，在開發階段，最好將其設置為“true”，因為它會通知我們代碼中的任何錯誤。 即使錯誤不會直接影響功能，它通常也會迫使您編寫更好的代碼並養成更好的編碼習慣。 它發生在我身上。 這也將確保您開發的插件或主題不會在任何 WordPress 安裝中生成 PHP 錯誤。

雖然這是大多數有經驗的開發人員都會做的事情，但它確實會發生，尤其是在匆忙中。 無論工作多麼緊迫，開發人員都應始終嘗試維護 WordPress 編碼標準，並明顯關注 PHP 最佳實踐。

6. 編寫 PHP 代碼而不考慮頁面可能會被緩存

這是一個常見的 PHP 錯誤，與前一個錯誤一樣，如果您堅持 PHP 編碼標準，則相對容易避免。

一些開發人員習慣於將 PHP 代碼片段實現到主題和插件中，這些代碼片段只有在 PHP 代碼一直被觸發時才有效。 例如，應該採取或不採取以某些動作響應 HTTP 用戶代理的 PHP 函數（例如，將僅用於移動用戶的腳本排入隊列）。

如果您的客戶端安裝了一個緩存頁面的插件（例如，W3 Total Cache 或 WP Rocket）而沒有觸發您的主題或插件中的條件，您的 PHP 代碼將變得無用。 如果目的是讓頁面響應，那麼這應該通過媒體查詢和 JavaScript 在前端完成。 後者，僅在確實需要時。 理想情況下，您希望避免使用 JavaScript 來使您的網站具有響應性。

7. 不通過 Git 等版本控制系統以專業的方式跟踪所做的更改

自定義編碼的文件，例如子主題或自定義插件，理想情況下應該受版本控制。 Git 創建更改的記錄，並允許開發人員在同一個 WordPress 項目上一起工作，或者在網站出現問題時輕鬆恢復到以前的版本。 此外，客戶可以使用 Git 來跟踪為該特定項目僱用的所有開發人員所做的所有工作歷史，特別是如果它是一個大型的、長期的 WordPress 自定義網站。

儘管一開始可能會讓人望而生畏，尤其是對於初級開發人員來說，理解 Git 是值得的，而且像 SourceTree（我的最愛之一）這樣的 Git GUI 軟件將只是您與 Git 存儲庫交互的方式，使整個學習曲線更愉快。 一旦您了解了它的工作原理，請考慮查看 Toptal 開發人員的 Git 最佳實踐和技巧，其中更深入地解釋了使用 Git 的幾種方法。

8. 在不需要 CSS 和 JavaScript 文件時將它們排入隊列

擁有許多 HTTP 請求會使網站加載速度變慢，因此在 Google PageSpeed 中的得分較低，這可能會影響搜索排名。 由於插件之間的衝突，它還可能導致 JavaScript 錯誤。 例如，可能有兩個插件使用一個通用的 jQuery 庫，這可能會被加載兩次並可能導致問題。 真的，這是最好的例子，因為 jQuery 經常在實時網站上加載多次。 這可能是由於插件或主題編寫不佳而發生的。

9. 使用.php文件輸出 CSS 或 JavaScript 代碼而不是靜態.css和.js文件

我見過一些主題甚至 WordPress 插件，其中包含style.php類的文件，這些文件僅用於生成自定義 CSS 代碼並打印它。 顏色、字體大小和元素周圍的間距等內容在主題設置中設置，然後保存在數據庫中。 然後讀取 style.php（例如<link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ）並根據自定義設置生成 CSS 代碼已在儀表板中更新。

就 WordPress 性能而言，這確實是一種不好的做法。 以下是它的主要缺點：

  1. 由於 CSS 文件在head標記中加載（這是正常的，並且大多數都是這樣加載的），因此存在性能問題，因為瀏覽器必須在渲染頁面之前完全下載文件。 如果 WordPress 環境因為某些插件而變慢，那麼這將大大延遲加載時間。 即使使用緩存技術或僅加載 WordPress 環境的一部分以便從數據庫中檢索值。 最好改用靜態 .css 文件。
  2. 在 PHP 文件中，當開發人員需要檢查某些內容時，代碼（CSS 規則與 PHP 變量和條件子句混合在一起）將更難閱讀。 當然，該文件可以在瀏覽器中運行（儘管我確定它何時打印，它甚至不會縮進或看起來不錯）但是如果您有項目的本地副本並瀏覽主題的代碼並且您需要找到 CSS 或 JavaScript 語法（以防使用 script.php），那麼它會使可讀性更難。

解決方案：將任何自定義 CSS 保存在插件目錄之外。 示例： /wp-content/uploads/theme-name-custom-css/style-5.css 。 這樣，萬一主題或插件更新，自定義文件就不會丟失。

10. 沒有為 WordPress 插件和主題使用正確的架構（代碼組織）

根據插件的大小和性質（例如，獨立插件或僅在激活主插件（如 WooCommerce）時才起作用的插件擴展），必須設置正確的架構和代碼組織。

如果您必須為客戶端構建一個單一用途的 WordPress 插件，並且它與 WordPress 核心、主題和其他插件的交互有限，那麼設計複雜的類是無效的，除非您確定該插件稍後會顯著擴展在。

如果該插件將具有豐富的代碼，那麼使用面向對象的編程（OOP）編碼方法（有很多類）將是有意義的。 例如，如果您有很多簡碼，您可以將它們全部保存在一個單獨的類文件中，例如class.shortcodes.php ，或者如果有打算在儀表板和前端視圖中加載的 CSS 和 JavaScript 文件然後可以使用諸如class.scripts.php之類的一個類，並將前端文件排入諸如enqueue_public_scripts()之類的方法中，同時將要在enqueue_admin_scripts()方法中的管理區域中加載的文件排入隊列。

與其將 HTML 與 PHP 代碼混合，不如通過在插件和主題中實現 MVC 模式來將其分開。 一個很好的例子是 WooCommerce 插件。 它具有各種佈局的模板，也可以通過主題或各種過濾器輕鬆覆蓋，因為邏輯與設計分離。 包含 HTML 佈局的模板主要用於打印已處理的信息。 在 PHP 方法中包含 HTML 代碼通常是一種不好的做法（當然，少量 HTML 代碼也有例外），尤其是對於隨著規模增長而由多個開發人員維護的插件。

根據 WordPress 插件手冊，雖然有許多可能的架構模式，但它們可以大致分為三種變體：

  • 單個插件文件，包含函數
  • 單個插件文件，包含一個類、實例化對象和可選的函數
  • 主插件文件，然後是一個或多個類文件

11. 編寫代碼時不認真對待 WordPress 安全性

由於許多新手開發人員更關注客戶想要的結果，因此在 WordPress 開發中通常不會認真考慮安全性。 一切都很好，直到客戶的網站被黑客入侵或您在 WordPress.org 上發布的插件存在漏洞，導致數千個網站受到影響。 這些事情有時會發生，甚至自 CMS 早期以來，甚至 WordPress 核心都處理了相當多的安全漏洞。 我們有責任使其盡可能安全，並在發生某些事情時迅速採取行動，並確保我們發布一個可靠的、經過良好測試的補丁。

一些最重要的安全提示是：

XSS 漏洞：為避免這種情況，必須做兩件事：清理數據輸入和清理輸出數據。 根據使用的數據和上下文，WordPress 中有幾種方法可以清理代碼。 不應該相信任何輸入數據，也不應該相信任何將要打印的數據。 清理數據輸入的一個常用函數是sanitize_text_field() 。 它檢查無效的 UTF-8 字符，將單個 < 字符轉換為 HTML 實體，去除所有標籤，去除換行符、製表符和額外的空白並去除八位字節。 至於打印數據，輸出鏈接的一個很好的例子是esc_url()函數，它拒絕無效的 URL，消除無效字符，並刪除危險字符。

防止直接訪問您的文件：大多數主機都允許直接訪問文件。 但是，如果發生這種情況並且代碼沒有正確編寫來處理它，則可能會打印一些錯誤（例如，缺少未聲明的函數或變量），其中包含對潛在攻擊者有價值的信息。 您經常在插件和主題中看到的一個常見代碼片段是：

 // Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

如果沒有定義常量ABSPATH （應該適用於任何 WordPress 安裝），那麼腳本將退出並且不打印任何內容。

使用 Nonce：如 WordPress 文檔中所述，nonce 是“使用一次的數字”，以幫助保護 URL 和表單免受某些類型的濫用、惡意或其他方式的影響。

例如，儀表板中的以下 URL 將用於刪除帖子： http://example.com/wp-admin/post.php?post=123&action=trash — 當訪問此 URL 時，WordPress 將驗證身份驗證 cookie 信息如果您擁有正確的權限（例如，您是擁有所有權限的管理員），該帖子將被刪除。

攻擊者可以做的是通過在第三方頁面上製作鏈接，使您的瀏覽器在您不知情的情況下訪問該 URL，如下例所示： <img src="http://example.com/wp-admin/post.php?post=123&action=trash" />當向 WordPress 發出此請求時，瀏覽器會自動附加您的身份驗證 cookie，並且 WordPress 會認為該請求是有效的。

那是一個隨機數出現的時候，因為攻擊者將無法輕鬆獲得隨機數值（為實際登錄到 WordPress 的管理員生成）。 新的請求 URL 如下所示： http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204 ://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

如果沒有有效的 nonce，WordPress 將向瀏覽器發送 403 Forbidden 響應，其中包含眾所周知的錯誤消息：“Are you sure you want to do this?”

儘管大多數人並不認真對待 WordPress 的安全性，認為他們的網站永遠不會被黑客入侵，相信託管（這可能會有所幫助，但僅在一定程度上）以及他們購買商業插件/主題的事實（這通常會導致假設它們非常安全），我們應該始終對我們的網站進行滲透測試，以便在任何黑客能夠識別和利用它們之前識別可利用的漏洞。

請注意，那裡的大量黑客攻擊甚至不是由一個人進行的，目的是專門入侵您的網站。 通常，有機器人會自動掃描 WordPress 網站，一旦發現已知漏洞，就會被利用，服務器用於發送垃圾郵件，從數據庫中獲取私人信息，在網站的某些頁面中放置隱藏鏈接會導致各種狡猾的網站（例如，色情、非法藥物）。 有時，黑客被隱藏得如此之好，以至於您需要正確掃描您的網站並查看特定文件的更新日期以檢測被黑客入侵的代碼。 這就是為什麼重新安裝 WordPress（是的，如果您有最後一個版本，則使用相同的版本）是很好的原因，因此任何被黑客入侵的文件都將被真正的 WordPress 核心文件覆蓋。

12. 在不理解的情況下使用 WordPress 函數和代碼片段

通常，當開發人員陷入困境並在 StackOverflow 之類的地方找到解決方案時，他們只是對自己成功完成某些工作而無需費心理解該代碼背後的邏輯或是否可以更改該代碼以更快加載或更少的事實感到滿意代碼行。

我已經多次看到這種做法，即在 PHP 腳本中復制代碼片段時，實際上只使用了三分之一的代碼。

這可能有一些缺點，包括：

  1. 該代碼不使用與現有項目代碼相同的樣式。 是的，只是複制和粘貼開箱即用的片段很舒服，雖然它們適用於小型個人項目（它可能有一天會變成一個大項目，誰知道），但這種做法通常並不好用於必須保持風格一致性的商業作品。
  2. 儘管代碼完成了它的工作，但它可能包含不推薦用於需要完成的任務的無效功能。 如果代碼沒有優化，這種“複製和粘貼”的做法可能會導致網站維護緩慢且難以維護，尤其是在項目中的不同位置使用多個片段時。
  3. 代碼可能未獲得重用許可，並且將代碼包含在客戶的項目中可能會給它們帶來很多法律問題。

不斷改進

每個人都會犯錯，每一個錯誤都是提升自己的機會。 作為 WordPress 開發人員，我們的行業發展速度非常快，而且從來沒有一套“正確的方法”來做事。 然而，你練習和學習的越多，你就會變得越好。

您是否不同意我指出的任何錯誤，或者認為我遺漏了一個？ 在評論中讓我知道，我們將討論。

相關：我的五個最糟糕的 WordPress 開發錯誤