修復 WordPress 網站的 4 個技巧

幾天前，一位朋友打電話告訴我，他的任務是維護一個舊的 WordPress 項目。 顯然，該網站已經三年多沒有更新了，到處都是問題。 這個可憐的傢伙完全被卡住了，因為他無法更新那裡的任何東西：插件、主題、內容……什麼都沒有。 所有操作（除了瀏覽網站本身）都會導致 WordPress 崩潰並返回錯誤。

當我們有一個無法使用的 WordPress 不斷產生錯誤並且無法更新時，我們必須做的第一件事就是確定它為什麼會這樣。 也就是說，我們需要找到罪魁禍首。 通常，您在 WordPress 網站上可能遇到的任何問題都是由於您的主題或一個（或多個）插件而發生的。

考慮到這一點，修復 WordPress 網站的通常程序是識別有問題的插件，從等式中刪除它，更新所有內容，最後，看看我們是否可以在我們的網站上重新安裝和更新有問題的插件，或者我們應該尋找一個替換。 今天我要告訴你四個簡單的技巧來找出網站失敗的原因，從而能夠修復它。

使用我們服務器的錯誤日誌

假設它是一個插件導致了我們網站上的錯誤，我們要做的第一件事就是驗證上述假設。 這樣做有不同的公式。 就個人而言，我喜歡從查看服務器的錯誤日誌開始，它在 cPanel 中有自己的選項：

希望錯誤日誌不僅包含我們網站上發生的錯誤的踪跡，還包含有關它們發生的“位置”以及罪魁禍首的信息。 比如上週我在開發環境的錯誤日誌中遇到瞭如下問題：

 appserver_1 | [Mon Aug 24 09:18:20.977541 2020] [php7:notice] [pid 1107] [client 172.20.0.2:34396] PHP Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>yoast/v1/get_head</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugg ing in WordPress</a> for more information. (This message was added in version 5.5.0.) in /app/.lando/wordpress/wp-includes/functions.php on line 5225, referer: http://nab5.lndo.site/wp-admin/edit.php

該日誌報告了一個發生在 WordPress 自己的文件 ( wp-includes/functions.php ) 中的 PHP 通知，它沒有告訴我們任何關於“一個插件是罪魁禍首”的信息。 幸運的是，如果您閱讀了整條消息，您會看到它描述了失敗的原因（即調用register_rest_route函數）並提示我們可能出錯的地方：Yoast（看看它如何提到“ yoast/v1/get_head ” ？）。

錯誤日誌是快速找出何時/是否有問題的最簡單方法，如果是，錯誤背後的原因是什麼。 在這個特定的例子中，我發現我在使用 Yoast 時遇到了問題，我所要做的就是將插件更新到最新版本

從 WordPress 儀表板停用插件

不幸的是，並不總是可以訪問網站的錯誤日誌來找出事情發生的時間。 或者，如果您確實有權訪問日誌，則它可能不完整。 在這些情況下，我們需要替代公式來驗證（或反駁）我們的初始假設。

假設我們的網站由於插件錯誤而失敗，最簡單的方法是停用所有插件並檢查錯誤是否仍然存在。 如果不是，那麼罪魁禍首就是插件； 如果它持續存在，則問題出在其他地方。

為此，請轉到 WordPress 儀表板 »插件，選擇所有活動插件，然後批量停用它們：

並檢查錯誤是否仍然存在。 如果沒有，您就知道問題是由您剛剛停用的插件之一引起的。 現在是時候準確地發現哪一個了。

要識別故障插件，您可以將它們一一激活，並檢查錯誤何時再次出現。 或者，如果你想走得更快，你可以應用以下步驟：

1. 激活一半的插件。
   1. 如果錯誤再次出現，則罪魁禍首在您剛剛激活的那一半，因此您可以安全地激活另一半。
   2. 如果錯誤沒有出現，罪魁禍首在另一半。
2. 一旦你知道有問題的插件在哪個“組”中，你只需要關注那個並重複這個過程。 激活該組的一半並停用另一半（即您現在要檢查總數的四分之一），然後查看您的網站是否正常工作。
3. 重複這個過程，直到找到罪魁禍首。

一旦您知道哪個插件出現故障，如何解決問題就取決於您了。 您可能必須聯繫開發人員，嘗試自己修復插件，甚至考慮用替代品替換它。 但是，至少，你現在知道你需要做什麼來擺脫這個問題。

備份您的活動插件列表

還記得我一開始的朋友嗎？ 當我們調查他的網站時，我們按照之前的所有步驟，停用了他網站上的所有插件……

…導致白屏死機！

顯然，網絡上充滿了自定義插件和主題調整，並且有很多交叉依賴。 通過停用插件，主題所依賴的某些功能不再可用，從而引發了致命錯誤。 這顯然是一個不好的做法：主題不能依賴於激活的插件。 如果它需要某個插件提供的某些功能，它必須實施安全檢查以驗證它們是否可用。

無論如何，問題是該站點已完全關閉，我們無法使用儀表板重新激活插件。 那麼這裡的解決方案是什麼？ 好吧，對於初學者來說，您應該始終備份您的網站……但在這種特殊情況下，手頭有一個更簡單、更快捷的解決方案。

在您的 WordPress 數據庫中，有一個名為wp_options的表。 在那裡，您會找到一個名為active_plugins的選項。 它的值是一個包含所有活動插件的數組。 因此，在使用我之前提到的批量操作停用插件之前，只需將此值保存在文本文件中：

這樣，如果“停用所有插件”最終導致不太可能（但並非不可能）的 WSOD，您可以通過恢復數據庫中的active_plugins選項來重新激活所有插件。

如何通過 FTP 停用插件

如果您知道您的問題是由特定插件產生的，但您無法從 WordPress 儀表板停用它，您可以通過 FTP 安全地執行此操作。

如您所知，插件只不過是一組文件。 當你在你的網站上安裝一個新插件時，它的代碼最終會出現在 WordPress 的wp-content/plugins文件夾中。 利用這些知識，我們可以通過從所述文件夾中“刪除”插件來停用插件。

轉到服務器的 cPanel 並查找 FTP 選項：

然後，使用 FTP 文件資源管理器，找到wp-content/plugins文件夾並找到您的插件：

現在，您所要做的就是刪除插件或重命名其文件夾，以便 WordPress 找不到它。 這樣，如果您登錄到您的 WordPress 站點，WordPress 將不再看到該插件並且將無法加載其錯誤代碼，從而解決了您遇到的問題。

使用默認主題

最後，如果問題是由您的某個插件引起的假設不成立，那麼下一步就是假設罪魁禍首是您的主題。 在這種情況下，您所要做的就是安裝一個默認的 WordPress 主題（例如 Twenty Twenty）並查看問題是否消失。 如果它消失了，你就已經知道你原來的主題有問題了； 如果沒有，那我們將不得不在另一篇文章中討論。

如果出於某種原因，您無法訪問 WordPress 儀表板，您可以通過 FTP ( wp-content/themes ) 上傳來在您的網站上安裝一個新主題，並使用數據庫更改活動主題：只需修改wp_options中的選項template和stylesheet 。 例如，您可能希望將這兩個選項都設置為twentytwenty ，假設這是您上傳的主題。

總之

普通的 WordPress（沒有插件和自定義主題）不太可能失敗。 因此，如果您的網站出現問題，那麼罪魁禍首很可能是您的插件或主題之一。 在今天的帖子中，我們看到了找到罪魁禍首、將其排除在外並恢復網站的不同公式。 我真誠地希望您不需要使用任何這些技巧……但如果您這樣做了，我希望它們會有所幫助。

我朋友的網站呢？ 嗯，我不知道——有人說他轉行了……

Olia Nayda 在 Unsplash 上的特色圖片。