WordPress 白屏死機：恢復指南

WordPress，就像現在的 MacOS 甚至 Windows 一樣，有一個臭名昭著的“死亡白屏”或簡稱“WSOD”。 出現嚴重錯誤時會出現 WSOD。 出於未知原因，您面臨空白或幾乎空白的白色屏幕。 怎麼辦？

什麼是 WordPress 白屏死機 (WSOD)？

在正常情況下，您不太可能在 WordPress 網站上遇到“白屏死機”(WSOD)。 它只是一個空白的白色屏幕，而不是 WordPress 網站的公共前端或後端界面。 這意味著 WordPress 已經崩潰，無法正常加載。

為什麼？ 出了什麼問題？

自 WordPress 5.2 於 2019 年 5 月發布以來，WordPress 具有恢復模式來保護您免受 WSOD 的侵害。 如果沒有恢復模式，兼容性問題將導致大量 WSOD 和沮喪的 WordPress 用戶。 如果您的服務器使用的 PHP 或 MySQL 版本不受您正在安裝的插件、主題或擴展的支持，您將獲得恢復模式，而不是破壞您的站點。 今天，PHP 內存不足 (OOM) 錯誤可能是最常見的剩餘情況，它會繞過 WSOD 保護，讓您的屏幕完全空白。

我諮詢了 WordPress 核心貢獻者 Marius Jensen，以了解現在還有什麼可能導致真正的 WSOD。 Marius 是 Site Health（現為 Health Check and Troubleshooting）插件的作者，其概念和功能最終進入了 WordPress 核心。 （這就是我們獲得恢復模式和其他保護的方式。）Marius 證實，讓 WordPress 在完全空白屏幕下崩潰的唯一方法是中斷 PHP 的執行流程，這樣致命錯誤處理程序就無法正常運行。 斷開 PHP 和 HTTP 服務器之間的連接將實現這一點。 您不會在屏幕上收到任何故障排除反饋。 那會令人沮喪，但如果您只是在 WordPress 內部工作，安裝和配置插件，這不太可能發生。

白屏死機是否意味著 WordPress 已被黑客入侵？

不，WSOD 並不意味著壞人抓住了你。 但是，在極少數情況下，這可能是安全漏洞的副作用。 如果您認為黑客入侵了您的網站，請轉到 Kathy Zant 的指南，如何清理被黑的 WordPress 網站。

PHP 編碼錯誤、兩個或多個插件之間的衝突或服務器環境中的問題是導致 WSOD 的最可能原因。 幸運的是，這些都不是災難！ 您的網站及其內容並未丟失。 如果願意，您可以自己修復 WSOD。

在本文中，我們將列出 WSOD 的可能診斷和治療方法。 您將學習如何讓您的 WordPress 網站恢復生機。 您還將更深入地了解 WordPress 的工作原理。

查看預覽

WordPress 白屏死機：我這樣做了嗎？

是的。 白屏死機可能是某事的結果 你對你的 WordPress 網站做了。

WSOD 的原因通常出現在您剛剛安裝和激活的 WordPress 插件中。 或者，它可能是最近更新的結果。 新添加或更新的插件可能與另一個插件衝突。 在這種情況下，一個插件試圖做與另一個插件相同的事情，或者它們正在朝著相互矛盾的目的行事。

如果插件、主題或有故障的 PHP 代碼片段導致致命錯誤，您可能會收到 WSOD。 它們可能包含語法錯誤、錯誤或與您正在使用的 PHP 版本不兼容的代碼。 如果您或您的主機剛剛升級了您的 PHP 版本——這是一件好事！ — 不兼容的插件將開始拋出錯誤，並可能導致您的網站因 WSOD 而癱瘓。 如果您使用的是 WordPress 5.2 或更高版本，不兼容問題將激活恢復模式，這比真正的 WSOD 更有幫助。

通常，罪魁禍首是剛剛用插件、主題或自定義代碼更改的內容。

由於 WSOD 通常是對上次（或最近）影響站點功能的任何更改的響應。 查看所有最近的更改。 關注看起來最有可能導致問題的變化。 如果您剛剛安裝了一個新插件或修改了一些主題代碼，那麼這些是首先要查看的地方，看看可能出了什麼問題。

當 WordPress 幾乎死了

並非所有 WSOD 都是平等的，有些甚至不是真正的 WSOD。

您可能會收到某種錯誤消息，而不是完全白屏。 它可能是有關 HTTP 500 錯誤或丟失數據庫連接的服務器錯誤消息。 這可能是來自 WordPress 的嚴重錯誤消息。 或者，您的網站可能會為訪問者正常加載，但當您嘗試登錄時，您會看到死機白屏。 在其他情況下情況可能恰恰相反：您可以登錄 WordPress 儀表板，但您網站面向公眾的前端給每個人一個空白屏幕。

如果您的 WSOD 體驗符合這些描述中的任何一個，那麼好消息！ 您的網站幾乎已經死了。 復活它並不難。

如果您在訪問您的 WordPress 網站或嘗試登錄時確實發現自己面對一個完全空白的白屏，那就是真正的 WSOD。 您必須更深入地挖掘以確定是什麼原因造成的。

WordPress 恢復模式和死機白屏

幸運的是，對於任何面臨 WSOD 的人來說，恢復模式在 WordPress 5.2 中被引入以消除它。 恢復模式會捕獲很多致命錯誤並幫助您修復它們。 如果您使用的不是 WordPress 核心的最新主要版本，請從那裡開始。 了解最新情況！

由於 WordPress 的恢復模式，出現問題時很少會看到完全空白的白屏。 從 WordPress 6.1 開始，您會經常在灰色屏幕上看到一個白色窗口，並顯示以下消息：

舊版本的 WordPress 會顯示類似措辭的消息，例如“該站點遇到技術困難”。

如果您瀏覽到後端/wp-admin URL，還會有一條通知告訴您檢查您的管理員電子郵件帳戶以獲取更多信息：

在其他情況下，您可能會看到一個帶有粗體文本的白屏，其中描述了“內部服務器錯誤”以及修復站點的某種解釋和指導。

歡迎來到恢復

這是恢復模式。 WordPress 正在努力幫助您重新站穩腳跟。

首先要做的是檢查與您的 WordPress 管理員帳戶關聯的電子郵件地址。 WordPress 嘗試在其執行的所有代碼中識別緻命的 PHP 錯誤。

如果可能，WordPress 將“暫停”插件或其他出現故障的代碼。 WordPress 會阻止錯誤代碼的執行。 然後它將通過電子郵件將詳細信息報告給管理員。

在恢復模式電子郵件中，您會找到在恢復模式下登錄 WordPress 的說明和臨時鏈接。 （此鏈接有效期為 24 小時。之後，如果站點仍然出現嚴重錯誤，將發送一個新鏈接。）

專業提示：如果您沒有收到恢復模式電子郵件，您可以通過在以管理員身份登錄時將以下地址添加到您的基本站點 URL 來以恢復模式登錄 WordPress： /wp-login.php?action=entered_recovery_mode 。

這是您進一步調查的機會。 如果 Recovery Mode 已將特定插件識別為導致 WSOD 的原因，請將其停用。 這將為每個人恢復您的網站。 然後您可以調查此插件的任何已知問題。 檢查是否有更新。 聯繫負責維護它的人員。

在 WordPress 中，並非每個死亡白屏都是相同的

在少數例外情況下，WordPress 或您的服務器環境中的其他地方出現了問題。 更新或安裝過程可能已停止，使您的站點停留在維護模式。 您、您的託管服務提供商或您安裝的插件可能修改了php.ini或.htaccess文件並導致意外結果。 您現有的環境可能不支持新安裝的插件的要求。

WordPress 恢復模式無法應對這些情況，但它會在原本為白色的屏幕上產生可見的錯誤消息。 您的站點前端可能無法訪問，但管理員登錄屏幕和後端界面可能運行正常。

這些不是真正的 WSOD 情況，但它們同樣令人討厭。 通常，以下情況之一會導致它們：

1.你陷入了維護模式

在更新 WordPress 核心、插件或主題時，WordPress 進入“維護模式”。 瀏覽到網站的任何部分都會顯示一個灰色的屏幕和一個白色的消息窗口，上面寫著：

有時這不會在一分鐘內解決，但質量管理的 WordPress 託管會注意到並通過自動化流程解決此問題。 如果您等待了幾分鐘沒有任何變化，您可以通過刪除安裝 WordPress 的 web/應用程序根文件夾中的.maintenance文件來退出維護模式。 （要查看它，您可能需要啟用查看文件名中以句點開頭的“不可見”文件。）

當沒有.maintenance文件時，您的站點將按預期加載。

2. 您已達到文件上傳或帖子大小限制

由於您發送的數據過多，您的網站可能會在上傳、發布後或表單提交過程中超時並出現白屏。

解決方案：增加wp-config.php中的帖子內容限制：

 ini_set('pcre.recursion_limit',20000000);
ini_set('pcre.backtrack_limit',10000000);

解決方案：在php.ini中增加文件上傳和發布大小限制：

 upload_max_filesize = 256M
post_max_size = 256M

延長帖子或任何表單提交超時之前的時間（以秒為單位）也可能有所幫助。 您還可以增加 PHP 執行腳本和解析輸入的時間。 此外，我們可以增加表單提交中允許的變量數量。 最後，我們可以指定 PHP 將提交的數據視為垃圾的時間限制：

 最大執行時間 = 300
最大輸入時間 = 300
最大輸入變量 = 1000
session.gc_maxlifetime = 1000

或者在.htaccess 、 httpd.conf或virtualhost中：

 php_value upload_max_filesize 256M
php_value post_max_size 256M
php_value max_execution_time 300
php_value max_input_time 300
php_value max_input_vars 1000
php_value session.gc_maxlifetime 1000

或者在 WordPress 或主題functions.php文件的自定義代碼片段中：

 @ini_set( 'upload_max_filesize', '256M' );
@ini_set( 'post_max_size', '256M' );
@ini_set( 'max_execution_time', '300' );
@ini_set('max_input_time', '300' );
@ini_set('max_input_vars', '1000' );
@ini_set('session.gc_maxlifetime', '1000' );

這些參數中的內存和時間值只是建議。 為確保它們正常工作並檢查它們的當前值，請使用 WordPress 管理界面中的站點健康工具。

除了恢復模式，WordPress 5.2 還引入了站點健康工具。 這對於診斷問題和獲取有關站點設置和服務器環境的技術信息非常有幫助。 在“工具”>“站點運行狀況”下的“管理菜單”中找到它。 您還可以從 WordPress 的健康檢查和故障排除插件中的擴展功能中受益。

3. PHP內存不足

PHP 是 WordPress 核心所基於的服務器端腳本語言。 如果 PHP 沒有足夠的內存來運行 WordPress 和您的活動插件，則會出現 WSOD。 您可能會在錯誤消息或日誌中看到這一指示。

根據您的託管計劃，您可以增加服務器上所有應用程序或特定 WordPress 實例的 PHP 內存限制。 如果您不確定該怎麼做，請向您的託管服務商的技術支持團隊尋求幫助。

wp-config.php

通常，在您的 WordPress 文件夾中的wp-config.php文件中添加以下設置將在本示例中將 WordPress 的前端內存限制設置為 256 MB：

 定義（'WP_MEMORY_LIMIT'，'256M'）;

128 到 256 MB 應該綽綽有餘。 您還可以通過將以下行添加到wp-config.php來定義分配給 PHP 的最大內存或後端內存（在下一個示例中也是 256 MB）：

 定義（'WP_MAX_MEMORY_LIMIT'，'256M'）;

第二個數字是最大內存限制，定義了 PHP 自身可用的總內存。 第一個數字是在更大的 PHP 限制內運行的 WordPress 的內存。 最大 PHP 內存限制應等於或高於 WordPress 應用程序內存限制。

文件

定義 PHP 最大內存限制的另一種方法是在位於 WordPress 文件夾中的php.ini文件中進行設置：

 內存限制 = 256M

確保行首沒有分號！ 請注意， php.ini只會影響在php.ini文件所在的文件夾中或文件夾下運行的 WordPress（或任何其他 PHP 應用程序）實例php.ini位於此處的php.ini文件將管理所有PHP 應用程序的環境設置，除非它們有自己的php.ini文件來指定不同的條件。

.htaccess

如果您使用 Apache 或 Litespeed 作為 HTTP 服務器，定義 PHP 內存限制的第三種方法是通過 WordPress 文件夾中的.htaccess文件。 像上面的例子一樣，.htaccess 需要有一個像這樣的未註釋的行來設置 256 MB 的最大 PHP 限制：

 php_value 內存限制 256M

wp-config.php 、 php.ini和.htaccess中應用程序和服務器設置的語法錯誤也可能導致 WSOD。 如果它們破壞了您的站點，您可能需要手動更正它們或將它們替換為原始默認值。 如果您使用的是 Apache 或 Litespeed 網絡服務器，那麼管理它們如何運行的.htaccess文件可以被許多 WordPress 插件更改。 任何這些文件中引入的錯誤都可能引發 WSOD 並導致您的站點癱瘓。

4. 你的 HTTP 服務器崩潰了

HTTP（或其加密的安全形式 HTTPS）是使 Web 服務器成為 Web 服務器的超文本傳輸協議。 這是服務器如何根據請求向客戶端（如瀏覽器）提供網頁（HTTP 文檔）。

WordPress 站點常用的 HTTP 服務器是 Apache、Litespeed 和 NGINX。 它們的錯誤屏幕看起來略有不同，並且瀏覽器顯示它們的方式可能有所不同，但它們都報告相同的 HTTP 錯誤代碼。

HTTP 500 錯誤，也稱為內部服務器錯誤，表示您的 HTTP 服務器出現意外問題，導致無法完成 HTTP 請求。 其他 5xx 服務器錯誤代碼，尤其是 502（錯誤網關）、503（服務不可用）和 504（網關超時），表示您的服務器過載或無法訪問。 500 內部錯誤是服務器故障的一個包羅萬象，導致服務器無法返回請求的頁面/文檔。

您的瀏覽器可能會提供自己獨特的 HTTP 錯誤屏幕，並且可能會顯示自己的特殊錯誤代碼。 如果您在使用 Chrome 時在地址欄中瀏覽到chrome://network-errors/ ，Google Chrome（和其他基於 Chromium 的瀏覽器）會在內部列出並解釋所有自己的錯誤代碼。

服務器端問題

WordPress 網站常用的 HTTP 服務器軟件包括 Apache、Litespeed 和 NGINX。 許多 WordPress 主機將它們與緩存一起使用以最大限度地提高性能。

如果硬刷新瀏覽器或清除瀏覽器 cookie 和緩存不能消除 500 錯誤屏幕，則您可能會獲取一些錯誤的服務器端緩存文件。 服務器端緩存在運行不佳時會引起很多混亂，因此您也應該嘗試清除它。 您的主機控制面板或 WordPress 管理界面可能具有緩存清除控件。

HTTP 500 錯誤的常見原因可能包括以下服務器端情況：

1. 已超出 PHP 內存限制。
2. PHP 未設置為顯示錯誤時的其他 PHP 錯誤。
3. 訪問服務器文件和文件夾的權限不足。
4. .htaccess 配置文件中的語法錯誤。

我們已經解決了 PHP 內存限制以及如何增加它們。 我們將在下一節深入探討 PHP 調試。

不正確的權限不應發生在現代管理 WordPress 主機上，但它們在傳統共享主機上很常見。 文件應設置為 664 或 644，文件夾應設置為 775 或 755，wp-config.php 應設置為 660、600 或 644。在 WordPress.org 了解有關更改文件權限的更多信息。

如果您更改了 .htaccess 文件或正在使用更改它的插件（通常或緩存），您可能需要檢查它是否有錯誤、恢復它或重新創建一個新的、有效的 .htaccess 文件。 在 WordPress.org 了解更多關於.htaccess的信息。

客戶端問題

HTTP 500 錯誤也可能由其他情況在客戶端（在您的瀏覽器中）引起：

5. 瀏覽器設置不正確。
6. 損壞的緩存。
7. 在瀏覽器中運行的損壞的 JavaScript 文件。
8. 互聯網連接問題。

嘗試在不同的瀏覽器中加載您的網站，以消除當前瀏覽器的問題。 如果您確實遇到瀏覽器問題，請嘗試將其重置為默認設置。 禁用您安裝的任何瀏覽器擴展程序或插件，看看它們是否與您的網站交互不良。

如果您的問題與錯誤的緩存文件有關，您仍然可以訪問未緩存的 WordPress 管理區域。 如果您仍然可以登錄到 WordPress 管理界面，您可以在那裡使用緩存清除開關或嘗試下面討論的其他故障排除步驟。

數據庫問題、WordPress 站點中的插件或主題問題或 WordPress 本身問題也可能導致 HTTP 500 錯誤。

要解決 HTTP 500 錯誤，您應該為 HTTP 服務器和 PHP 打開錯誤日誌記錄。 然後檢查兩者中出現的錯誤。 您還可以檢查並可能增加 PHP 內存限制、停用插件並切換到默認主題，以查看是否有任何這些操作可以使您的網站恢復正常。

我們將在下面更詳細地介紹這些步驟。 如果遵循它們不能消除 500 錯誤，請聯繫您的網絡託管服務商的支持團隊以獲得進一步的幫助。

當 WordPress 真的死了

如果您在 WordPress 網站的每個前端和後端頁面上都看到完全白屏，並且根本看不到任何錯誤反饋，那就是完整的 WSOD 體驗。 如果您知道如何訪問 PHP 錯誤日誌和 HTTP 服務器日誌，您可以獲得一些錯誤消息和診斷信息。 為 WordPress 打開 PHP 調試是另一種選擇。 您的主機可能有一些工具可以讓您更輕鬆地進行調試。 但如果情況並非如此，您可以簡單地查看此常見 WSOD 的治療列表，直到找到您的解決方案。

故障排除和修復 WordPress 白屏死機的主清單

要修復 WordPress 白屏死機，請按照以下步驟找到解決方案。 它們是按照我遇到過的最常見的 WSOD 原因順序組織的，但您可以按任何順序嘗試它們。

優先考慮與您的特定情況最相關的解決方案是最有意義的。

錯誤記錄和調試步驟 (#2) 是最技術性的，但它是徹底的並且總是會告訴你是什麼導致 WordPress 終止。

我提供了幾個免費插件的鏈接，它們可以成為有用的診斷和修復工具。 您可能還會發現 iThemes Security 的數據庫掃描和修復功能以及文件更改檢測特別有用。 它甚至具有服務器工具，可以更深入地了解您的服務器設置和功能。

最後，一個好的、最近的備份將使您的網站恢復到最後已知的良好狀態。 Backup Buddy 是這個角色的最佳插件。

清除瀏覽器緩存和 Cookie

瀏覽器和服務器中站點的緩存頁面可能會向您顯示與實際情況不同的內容。 讓我們確保您看到的是 WordPress 向您網站的全新訪問者展示的內容。

首先，清除瀏覽器的緩存和 cookie。 如果您登錄到 WordPress 或任何其他站點，這將結束您的用戶會話，以便您像其他訪問者一樣查看它。

接下來，使用您的託管面板和 WordPress 管理員（如果可用）清除您的主機和 WordPress 緩存插件正在創建的任何服務器端緩存。 嘗試關閉所有站點和服務器緩存。 在瀏覽器中執行硬刷新。 如果這樣可以解決問題，則問題可能是您激活了緩存設置但在您的系統上不起作用。 通過排除過程，您可以確定哪些有效，哪些無效。

2. 查找 PHP 錯誤

WordPress 核心、主題或插件中的 PHP 代碼可能會產生致命錯誤，這將使 WordPress 放棄死機白屏。

要獲得有關致命 PHP 錯誤及其原因的更多信息，您可以打開 PHP 錯誤報告並將其發送到屏幕、日誌文件或兩者。 致命錯誤可能指向 WSOD 的來源。

作為基於 PHP 的 Web 應用程序，WordPress 有自己的調試診斷報告系統，可幫助您利用 PHP 的錯誤記錄功能。 要打開並控制它，請確保wp-config.php中有一行內容為：

 定義（'WP_DEBUG'，真）；

您可能需要添加它或將值從 false 更改為 true。 這告訴 WordPress 打開 PHP 調試。

您還可以通過安裝和激活 WP 調試插件來走捷徑。 它將為 WordPress 啟用 PHP 調試，而無需您自己直接修改wp-config.php 。

下面顯示的附加wp-config.php參數會將調試輸出作為 HTML 打印到屏幕，默認情況下名為“error_log”的文件：

 定義（'WP_DEBUG_DISPLAY'，真）;
定義（'WP_DEBUG_LOG'，真）;

強制 WordPress 使用其 CSS 和 JavaScript 依賴項的非優化版本也可能會有所幫助，因為它們可能會導致問題：

 定義（'SCRIPT_DEBUG'，真）;

Debug Bar 插件是一個有用的附加和補充工具。 它將在一個漂亮的界面中向您顯示調試數據。

為此，在php.ini中必須有一行為error_reporting常量提供NONE以外的值，例如error_reporting = E_ALL 。 此行的標題不應有分號； 這使它成為評論而不是活動設置。 請注意，如果您使用E_ALL ，您將收到每個PHP 錯誤、警告和通知。 使用不同的值（如E_ERROR ）僅記錄導致 WordPress 崩潰的致命運行時錯誤。

3.檢查主題和插件衝突

如上一步所述調試 PHP 錯誤應該指向一個明確的主題或插件文件作為 WSOD 的來源。 您還可以使用技術性較低的消除過程方法來關閉它。

故障排除主題

白屏死機通常是由 WordPress 主題和/或插件之間的衝突引起的。 要確定衝突源，您可以嘗試停用所有插件並切換到帶有 WordPress 核心的當前未修改的默認主題包，例如 Twenty-Twenty-Three。

從主題開始——這是最容易測試的。 如果將您的活動主題切換為已知良好、未經修改的默認主題使您的網站恢復在線，則您知道問題出在您一直使用的主題上。

查看您主題的functions.php文件（如果有的話）。 如果您最近更改了它，那很可能是您不幸的根源。 functions.php文件是添加自定義功能代碼的地方，以便在激活時與主題一起使用。 這裡的錯誤代碼和語法錯誤會給你一個 WSOD。

插件故障排除

您可以停用插件，而無需通過命令行/SSH 或 SFTP 訪問 WordPress 管理員，只需將插件文件夾暫時移出/wp-content/plugins/文件夾即可。 我的做法是創建一個名為“A”的插件子文件夾，以便它首先出現在按字母順序排序的/plugins目錄中。 然後我將所有其他插件文件夾移動到“A”。

完成此操作後，重新加載您的網站。 WordPress 的行為就好像插件都消失了一樣。 它們仍然安裝但已停用。 如果白屏死機消失了，您可以嘗試一個一個地重新激活您的插件和主題，每次都刷新您的主頁，看看是哪個導致您的網站崩潰。

Meks Quick Plugin Disabler 是一個方便的工具，可以快速禁用所有活動插件，然後根據您的命令從 WordPress 管理員內部重新啟用它們。

4.修復損壞的核心文件

您的 WSOD 可能是核心 WordPress 文件損壞的結果。 雖然這不太可能，但只需在 WordPress 儀表板更新區域中單擊一下即可快速重新安裝最新版本的 WordPress。 這不會損害您的任何插件、主題或現有內容，因此這是一種確認您的核心文件是否正常的好而簡單的方法。

如果上述步驟均無濟於事，則 WSOD 可能是由您無法控制的服務器環境問題引起的。 在這種情況下，您可能需要聯繫您的託管服務提供商尋求幫助。 作為最後的手段，您還可以通過恢復備份將您的站點回滾到“最後一次正確”狀態。

如何防止 WSOD——給 WordPress 網站所有者和建設者的建議

WordPress 工作得很好——然後突然之間出現白屏死機！

這可能是因為您更改了對 WordPress 功能至關重要的內容。

如果您在 Liquid Web 或 Nexcess 中使用可靠的託管 WordPress 託管帳戶，並為您正在做的事情正確配置了足夠的資源，則可以避免使用 WSOD 破壞 WordPress 的 99% 的方式。

問題是網站所有者不會避免這些做法！

不該做什麼

1. 牛仔編碼。 通過 SFTP、命令行或 WordPress 管理員中的代碼編輯器和腳本插入器在實時站點上添加或編輯功能代碼。 一個小錯誤就會導致網站崩潰。 更改.htaccess和wp-config.php等配置文件也可能導致站點崩潰。 而是在本地測試或實時（但不是公共）暫存站點上工作。
2. 安裝可疑的主題、插件和擴展。 將低質量甚至無效的軟件安裝到實時站點是在招惹麻煩。 簡單地一次添加太多東西會讓人很難確定最終什麼是重大變化。 與牛仔編碼類似，將新代碼產品安裝到實時站點中是有風險的。 首先在私人本地或暫存站點上進行良好測試。
3. 複雜的緩存。 您的主機可能提供的幾種服務器端緩存可能無法與所有緩存和性能優化插件一起正常運行。 當您實施新的緩存方法或設置時，在對實時站點實施更改之前，請在本地和暫存環境中仔細測試。
4. 一次更新所有內容。 您可以一次批量更新多個主題和插件。 通常這是有效的，但如果您的服務器超時，您可能會陷入維護模式。 此外，新更新的代碼可能會引入新的錯誤、衝突或兼容性問題。 如果發生這種情況並且您的站點出現故障，則將更難確定問題的根源。 如果您一次更新多個主題、插件和擴展，它可能是任意數量的項目。 更新後的代碼可以在本地和實時暫存站點上進行測試，然後再在您的主要公共站點上推出。

沒有 WSOD 生活的小貼士

WSOD 可能發生在任何 WordPress 站點上，但不應引起恐慌。 遵循本指南中的提示可以幫助您識別問題並在您的網站訪問者註意到之前快速修復它。

WordPress 網站的問題強調了適當維護和保養的重要性。 比對 WSOD 做出反應更好的是，您可以學習以一種永遠不會讓訪問者看到錯誤消息和空白屏幕的方式在 WordPress 上工作。

小心謹慎地進行更改。 在本地測試或暫存環境中處理潛在的 WSOD。 這些是當今大多數託管 WordPress 主機的標準工具和功能。 如果您遵循這些基本的最佳實踐，您就不必擔心 WordPress 白屏死機。

保護和保護 WordPress 的最佳 WordPress 安全插件

WordPress 目前為超過 40% 的網站提供支持，因此它很容易成為懷有惡意的黑客的目標。 iThemes Security Pro 插件消除了 WordPress 安全性的猜測，使保護和保護您的 WordPress 網站變得容易。 這就像擁有一名全職安全專家，不斷為您監控和保護您的 WordPress 網站。

獲取 iThemes 安全專業版

丹·克勞斯

Dan Knauss 是 StellarWP 的技術內容通才。 自 1990 年代後期以來，他一直是一名作家、教師和自由職業者，從事開源工作，自 2004 年以來一直從事 WordPress。