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。