使 WordPress 維護順利的 10 個技巧
已發表: 2022-03-11作為一名從事過各種類型項目的 WordPress 開發人員，我想討論一下我在使用現有 WordPress 網站進行編輯或錯誤修復時親身經歷的一些痛點。 本文中列出的提示和建議旨在最大程度地減少甚至擺脫這些痛苦。
為什麼正確的 WordPress 維護很重要
大多數時候，網站不是“一次性設置”的事情，所有網站都是如此，而不僅僅是 WordPress 網站。 有時，您將不得不處理您最喜歡的首選開發人員會處理的編輯、更新或錯誤修復。 但是，在某些情況下，您可能需要在網站的整個生命週期內依賴多個不同的開發人員。
在後一種情況下，對於新來的開發人員來說，事情通常不會順利進行，特別是如果以前的開發人員在處理他們的維護任務時未能遵守最佳實踐。
讓我們看看在您未來的 WordPress 項目維護工作中需要考慮的一些更重要的點，這樣您就可以讓下一個開發人員的生活更輕鬆，讓他們喜歡在您的網站上工作。 顯然，讓您的開發人員的工作更輕鬆也必然會在此過程中節省一些工時和金錢，這對於您的潛在客戶來說始終是一個很好的賣點。
1. 備份它！
這聽起來可能太明顯了，但第一件事就是第一！ 您需要定期正確備份您的 WordPress 網站。
即使您目前沒有對您的網站進行任何更改，這也是最基本的事情之一。 您可以通過抓取所有文件以及數據庫轉儲並將其存儲在安全的地方手動完成，或者您可以使用自動備份選項，由 WordPress 備份插件提供。 您可以在 WordPress 插件存儲庫中找到大量免費和付費插件。 您還可以在服務器級別充分利用備份選項，因為大多數託管服務提供商都提供備份選項——您需要與託管服務提供商核實。
通過定期備份，您可以放心，您的網站將在崩潰或錯誤後重新啟動並運行。 它還可以幫助您的新開發人員輕鬆解決問題，尤其是當您嘗試修復您懷疑在過去維護期間可能發生的錯誤時。 定期備份應該可以幫助您的新開發人員識別和解決揮之不去的問題，這些問題發生在他們接管項目之前的幾個月或幾年。
2. 在本地安裝您的 WordPress 網站
我並不自豪地承認我自己在早期就犯了這個錯誤，從那時起我注意到許多開發人員直接在遠程服務器上進行編輯。 除非您擔心敏感數據和所有站點文件都受開發人員的支配，否則您應該永遠避免這個錯誤。 每次編輯後在開發者的本地機器和服務器之間來回切換是非常低效的。
即使是微小的更改，例如更改站點上的一些文本的小修改，開發人員也必須導航到 FTP 客戶端中的相應文件/文件夾（如果您使用 FTP 進行文件上傳），等待要上傳的文件，並希望沒有偶爾的 FTP 連接失敗。 我們不要忘記，一些 WordPress 網站有太多數據無法實際移動，而不會浪費太多時間和帶寬。 而且，在成功上傳所有內容後，他們必須轉到瀏覽器並刷新頁面，這再次取決於當時網絡/服務器的速度和狀況。 看起來我們只是在談論每次更改可以節省的時間，但在您的項目過程中，這些時間可能會增加數小時的不必要工作。
如果您的開發人員在他們的本地計算機上安裝了站點，則編輯速度會快得多：他們只需要進行編輯，刷新頁面，就可以完成。 即使他們住在沒有任何互聯網連接的洞穴中，他們仍然可以工作並在以後上傳他們的更改。
如果您有您擔心的敏感數據，或者有一些法律原因阻止您與開發人員共享您的所有數據，該怎麼辦？ 在這種情況下，您可以為此專門準備一些虛擬數據。 您也可以保留這些數據以備將來維護。
3. 使用 Git
在軟件開發領域發生的最好的事情之一就是在線版本控制的曙光。 我提出這一點是因為有很多網站仍在使用傳統的 cPanel/FTP 方法來處理文件。 要么他們不知道版本控制有多好，要么他們知道但由於最初的設置工作而猶豫不決。 但是，這實際上並沒有那麼多工作，而且絕非一項艱鉅的任務。
在管理文件時，版本控制帶來了許多好處，包括跟踪不同作者的更改、輕鬆恢復編輯、為每個獨立任務擁有單獨的分支以確保每個任務的更改不會干擾其他任務。
您必須在外部服務器上設置 Git，大多數情況下您的託管服務提供商已預先安裝了該服務器。 您可能需要在服務器方面具有一定專業知識的人來啟動存儲庫並設置工作流，我不打算在這裡討論，因為它超出了本文的範圍。
更不用說，如果你不使用分支，你實際上並不是在“git'ing”！ 至少為開發和生產創建兩個分支，以便開發人員可以在開發分支上完成所有工作，測試站點，然後如果一切正常，推送到生產分支，確保實時站點上沒有任何問題。
4. 刪除不需要的文件、代碼和插件
留下不再需要的文件和插件是很常見的。 一旦文件在您網站的整個生命週期中隨著時間的推移而累積，這就會變得很痛苦。 如果您的開發人員不關心刪除隨著時間的推移添加的不需要的文件，那麼很難追踪它來自哪里以及它當前是否被網站的某些部分使用。 這會導致額外的頭痛，因為應該再次測試該站點以確保在移除這些可疑項目後沒有任何損壞。
這可以通過相應的開發人員立即刪除不需要的文件來消除。 您可以向所有開發人員強調這種做法。
除了 PHP 文件和插件之外，未使用的媒體文件也會隨著時間的推移填滿您的wp-content文件夾，這可能會給您的開發人員在使用任何與媒體相關的功能時帶來麻煩。 您可以找到各種插件來簡化此任務。 一個例子是媒體清潔器。
該插件具有內部垃圾箱，可暫時將文件移到那裡，以確保文件實際上沒有被使用； 檢查後，您可以永久丟棄它們。 在清理任何文件之前，請確保遵循本文中的第 1 點（即備份）。
5. 評論
您可能熟悉這樣的編程模因：編寫代碼時，編寫它的作者、同事和上帝都理解它。 過了一段時間，只有作者和上帝知道它做了什麼，現在只有上帝知道它做了什麼——除非作者添加了適當的評論！
一些開發人員在評論時可能不情願或完全懶惰，但這是在良好的開發環境中必須具備的實踐。 它減少了編輯和錯誤修復的時間，否則新開發人員甚至同一開發人員將花費這些時間來弄清楚特定代碼塊的作用。
每當函數/類或代碼塊不明顯時，都應添加註釋，例如以下函數：
function stripWhiteSapaces(str) { … Return str; }上面的函數名稱不言自明，用戶也不需要進入函數內部查看它是如何工作的，它只做一項工作，去除空格——就是這樣！ 因此，在這種情況下，可能不需要評論。
但是，例如，如果有一個函數接受多個參數並返回過濾後的帖子列表，那麼這不像前一個那樣明顯。 應該有描述參數及其類型的註釋。 可能還需要描述此函數內的代碼塊。
為了快速檢查，您可以從 WordPress 核心獲取一個文件，看看 WordPress 專家是如何評論它的。 或者，有關更多詳細信息，您可以參考 WordPress 的官方指南，該指南很好地說明了這一點。
6. 掉毛
Linting 是另一個很酷的功能，它在我們編寫代碼的方式上強制執行規則，有時它會糾正代碼格式本身，這既酷又有用。 當今使用的大多數 IDE 都帶有 linting 選項，您可以通過添加各種 linting 配置來進一步改進或自定義這些選項。
例如，當使用 Visual Studio Code 作為 IDE 時，VS Code 使用官方 PHP linter ( php -l ) 進行 PHP 語言診斷。 您可以分別為每種語言（即 PHP、JavaScript、CSS 等）配置規則/限制。 您可以查看 WordPress 編碼標準了解更多詳細信息。
- https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/
- https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/
一旦有了 linting 配置，就需要強制執行它。 您當前和未來的所有開發人員都需要將此 linting 配置集成到他們的 IDE 中，以便他們的代碼也遵守相同的規則/限制。 否則，你的大部分努力都將付諸東流。
7. 變量和文件命名
設計一個處理事物如何命名的標準。 這包括函數/類名、變量名、文件名，甚至媒體/圖像名（如果它是模板的一部分），因為它也有助於理解它們的用途。
考慮一些要點：
- 避免使用明確的名稱
- 盡可能保持簡短
- 有時將“類型”附加到文件名非常有用。 例如，如果它是一個圖標，您可以使用 BlackArrowIcon.png 之類的東西，或者如果它是一個大背景圖像，它可以是 FrontYellowBG.jpg 之類的東西。 或者，如果它是一個代碼文件，有時在 IDE 的不同選項卡中打開多個文件時，很容易知道該文件代表什麼。 例如，如果有一個具有輔助函數的類，如果將其命名為 HelperClass.php 而不是 Helper.php，將會很有幫助。
有關更多信息，請查看 WordPress 最佳實踐指南中的命名約定部分。
8. WordPress 調試
調試可能會花費大量時間，並且往往會在總開發時間中佔據很高的份額，尤其是在編輯或錯誤修復方面。 這意味著您必須注意您的開發人員是否以最有效的方式進行操作。 大多數開發人員傾向於通過手動var_dump在網頁的某些部分中對變量執行此操作，這不是最有效的方法。 這也可能讓以後加入項目的開發人員感到頭疼，因為如果在工作完成後沒有正確清理調試代碼，他們最終會到處出現垃圾代碼行。
有一些插件可以幫助完成這個調試任務。 以下是一些流行的 WordPress 調試插件示例。
- Kint 調試器
- 調試欄
- 查詢監視器
9. 有更好的 CSS
在 Web 開發方面，使用 CSS 進行樣式設置是最基本的活動之一。 不幸的是，這意味著它經常被忽視，並且比 JS、PHP 等受到的關注更少。但是，不管你信不信，如果你以後嘗試添加或編輯某些東西時，如果架構不正確，CSS 可能會導致巨大的麻煩，除非您的網站是基本的和小型的。
如果你有興趣更多地了解為什麼這種相對基本的樣式技術容易出現問題，你可以穀歌一下為什麼 CSS 很煩人，或者你可以閱讀更多關於 CSS 的 5 件最煩人的事情。
以下是我這邊的一些快速提示，沒有太多細節：
- 執行良好的命名習慣。 使用像 BEM（塊元素修飾符）這樣的命名方法
- 避免內聯樣式。 請改用外部樣式表。
- 盡可能嘗試提出常見的可重用模式，而不僅僅是在需要時增加樣式。
- 根據網站的功能或區域將樣式分解為多個文件。 如果你擔心更多的樣式文件可能會影響加載性能，你可以使用一個很好的緩存插件來克服這個問題，它將多個文件合併到一個文件中。
- 使用 CSS 預處理器，如 SASS、LESS 等。
10. 從當前開發人員那裡獲得反饋
作為最後的想法，並且為了使列表完整，您可以從開發人員那裡獲得有關他們在您的網站上工作時遇到的問題的反饋。 他們可能會提供一些很好的建議，因為他們是那些在您的網站上弄髒了手的人。 他們還可能指出以前開發人員留下的錯誤或臟代碼。