wordpress突然无法访问了
给打不开的网站提供一个有效的解决思路：从错误日志入手解决问题
站长在线（olzz.com）站长杨泽业，昨天收到一个建站客户发来的问题，我网站的英文的WordPress博客打不开了，主站和中文博客都能打开。帮我把网站弄得可以打开。我这次要分享的一个思路是从错误日志入手解决问题。
给打不开的网站提供一个有效的解决思路：从错误日志入手解决问题
我这个客户的网站是这样的结构，主站是使用蓝科cms搭建的中英文网站，然后在二级栏目，安装了一个中文博客，和一个英文博客。即一个虚拟主机里面有3套独立网站程序。
一分析，主站和中文博客可以打开，英文博客打不开。肯定不是网站空间的问题，而是程序源码的问题。打开FTP软件，居然ftp登录不了，致电GoDaddy中文客服，叫我删除了原来的ftp账号，新增一个ftp账户，ftp登录成功。
登录了ftp，第一时间查看了网站的错误日志文件（error_log），下载下来看了，错误的地方是/wp-settings.php on line 139，即在wp-settings.php的139行。找不到文件wp-includes/l10n.php。通过ftp查看，的确没有这个文件，从中文的博客里面把这个文件复制过来，问题解决，网站正常打开。
好了，如果大家的WordPress网站打不开的话，先分析错误日志吧。当然我这次遇到的是WordPress网站，其实什么网站都可以从错误日志里面去分析，哪里出了问题，就从哪里开始找出问题，解决问题。
欢迎关注站长在线官方头条号【站长快递】学习更多的建站知识！
吐血整理：碰到 WordPress 致命错误，如何一步一步解决
WordPress 用户最头疼的问题就是站点白屏打不开了，或者后台进不去了，这就是 WordPress 的致命错误，英文是 White Screen of Death（白屏错误），简称：WSoD。
同样类似的，使用 WPJAM Basic 插件的用户，问得最多的问题是：为什么开启 WPJAM Basic 之后，xxx 主题不可用，xxx 插件用不了呢？
其实这些都是因为兼容问题，造成了 WordPress 致命错误。一般我的建议是停用其他插件，换用默认主题，看看还有没有问题，然后一个一个排除。
下面我们详细讲解一下什么是 WordPress 致命错误，我们怎么一步一步定位它和解决它。
什么是 WordPress 致命错误就是网站平常访问没有问题，突然屏蔽成了白屏了，也可能因为使用不同的浏览器得到不同的错误信息，比如在 Chrome 浏览器下显示的 HTTP 500 错误：
如果火狐浏览器，那么就是白屏了，没有任何有用的信息：
如果 WordPress 开启了致命错误处理，那么就会显示下面的信息：
WordPress 的致命错误都是 PHP 代码错误引起，或者内存限制引起的，一般是一些错误的主题或者插件的代码，比如插件和主题使用了相同的函数，造成冲突了。
所以 WPJAM Basic 插件的大部分问题就是上面所说，其他插件或者主题使用和 WPJAM Basic 相同的函数或者类库，造成了冲突引起的。
那么怎么解决这些问题呢？
仅仅是本站还是所有站点？如果服务器安装多个 WordPress，看看其他站点有没有问题，如果有同样的问题，可能是服务器出问题了，联系一下服务商，看看是不是线路或者服务器出问题了。
这也是我一直建议使用阿里云和腾讯云这类服务器，因为一般不会莫名出现这类问题，如果出现问题，他们也会很快修复。
如果仅仅是该站点的问题，那可能是真的是这个站点的代码出问题了，那就针对该站点就行深究了。
PHP 的内存限制造成的？很多时候出现白屏是因为，PHP 脚本的执行需要大量的内存，而服务器的限制使得 PHP 脚本得不到满足，比如下面的错误代码，这种情况有可能是程序写了死循环了，或者真的需要那么大的内存。
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 2348617 bytes) in /www/xxx/wp-includes/plugin.php on line xxx
我们先尝试增大一下 PHP 脚本的内存限制看看能不能解决问题，在 wp-config.php 文件增加下面这行，把限制修改为 256M：
define( 'WP_MEMORY_LIMIT', '256M' );文件权限引起问题？
还有一个可能引起白屏的原因可能是文件的权限和所有者，这个处理有点麻烦，如果不是很熟悉建议找个专业的人员帮你处理一下。
一般来说对于 WordPress 来说，文件的权限规则是：
文件应该设置为 664 或者 644.文件夹应该设置为 775 或者 755.wp-config.php 文件应该设置为 660, 600, 或者 644.如果你可以使用 SSH 登录你的服务器，可以在 WordPress 根目录下的执行下面这行命令一次搞定：
sudo find . -type f -exec chmod 664 {} +sudo find . -type d -exec chmod 775 {} +sudo chmod 660 wp-config.phpWordPress 插件冲突了？
如果还不能解决问题，那么接下来，解决 WordPress 致命错误的方法就是先停用所有插件，一般来说一个站点挂了很大原因是一个有问题的插件。
1. 如果还能访问 WordPress 管理后台，最快的方法就是到后台的插件页，选择所有插件，在批量操作下拉菜单中选择停用。
如果停用所有插件之后可以解决问题，那么接下来我们要找出具体是哪个插件导致问题的，一般我们是通过一个一个激活插件来发现，每激活一个插件，在出问题的界面刷新一下，如果问题重现，我们就可以定位是哪个插件出的问题了。
2. 如果后台已经无法进入，那就只能通过 FTP 来处理了，进入网站的 wp-content 目录，然后再把 plugins 文件夹改成 plguins-old 目录。
改名之后检查一下网站是否可以访问，如果可以访问，那么接下来要一个一个检查插件了。把插件目录改回「plugins」，然后在插件目录中，对每个插件进行重命名的方法，来定位出问题的插件。
WordPress 主题不兼容？如果问题不是插件引起，很可能是主题引起的，所以很多使用 WPJAM Basic 问题大部分是主题引起的，很多主题使用的函数和 WPJAM Basic 函数冲突了。
比如我在博客上介绍一些自己写的一些工具函数，这些函数都尽量 wpjam_ 开头了，但是有些主题没有改，直接拿过去用了，WPJAM Basic 插件里面也有，那么就冲突了。
1. 我们可以通过切换回 WordPress 默认的主题来定位问题，如果还能进入后台，那么进入「外观」-「主题」，选择一个默认的 WordPress 主题，比如最新的 2021：
然后在出问题的界面刷新一下，如果问题重现，那就是主题的问题。
2. 如果无法进入后台，处理方法和上一节处理插件一样的，使用 FTP 工具进入 wp-content 目录，重命名一下 themes 文件夹。
这样 WordPress 会自动使用最新的默认主题，比如现在就是 2021。最后测试，如果问题重现就是插件的问题了，如果确定是，可以考虑换个主题。
浏览器和 WordPress 的缓存有问题？浏览器的缓存和插件的缓存也可能引起致命的错误，建议先清理掉。
如果你安装了缓存插件，比如 WP Rocket 或者 WP Super Cache，最快删除缓存的办法，通过插件的设置页面。
比如 WP Super Cache，在「设置」-「WP Super Cache」-「删除缓存」即可清理掉缓存。
如果无法进入 FTP，那么缓存的文件在 wp-content/caches 目录下，可以进入进行删除操作。
放大招：开启 WordPress Debug 模式如果还不能解决问题，那就用最后的大招了，直接定位错误的 log，我们是忽略前面的方法直接用这个来解决的。
对于程序员来说，出现问题最重要的是知道是什么问题，问题的细节，具体的错误 log，这样就要开启 WordPress Debug 模式。
WordPress 提供了 WP_DEBUG WP_DEBUG_DISPLAY 和 WP_DEBUG_LOG 这三个常量让你应对各种情况，下面讲经常经常使用到的方法：
1. 如果是前台和后台空白，并且没有显示任何错误。
打开 wp-config.php 文件，将原来的 WP_Debug 设置改成如下设置：
define('WP_DEBUG', true);define('WP_DEBUG_DISPLAY', true);
这样就可以直接看到错误的信息：
Cannot redeclare get_posts() (previously declared in /var/www/html/wordpress/wp-includes/post.php:1874) in /var/www/html/wordpress/wp-content/plugins/test-plugin/test-plugin.php on line 38
比如上面的错误信息就是在 test-plugin 插件定义了 get_post 函数，这个函数 WP 内置了，函数名冲突了。
2. 错误是发生在某些后台进程，比如 cron job 或者微信自定义回复的时候，没法显示错误 log，我们可以把 log 保存到 debug 文件。
打开 wp-config.php 文件，将原来的 WP_Debug 设置改成如下设置：
define('WP_DEBUG', true);define('WP_DEBUG_DISPLAY', false);define('WP_DEBUG_LOG', true);
然后就可以在 wp-content/debug.log 文件中看到相应的错误信息了。
最后一定要记得，测试完了一定要改回去，就是：
define('WP_DEBUG', false);
不然，你的用户也会看到你的系统错误了，或者 wp-content/debug.log 很大，把你服务器的空间都用完。
附加技巧：增强 PHP 文本处理能力如果还没有解决你的致命错误，并且错误是发生在文章编辑页，并且很小的概率是因为文章太长造成的。
如果是这种情况，我们可以尝试一下增加回溯和递归限制来增强 PHP 文本处理能力，在 wp-config.php 文件添加下面的代码：
/* 针对超长文章的技巧 */ini_set('pcre.recursion_limit',20000000);ini_set('pcre.backtrack_limit',10000000);总结：耐心处理和提供 log
WordPress 出现了致命错误并不可怕，按照这篇文章提示的方法一步一步整理，总能解决问题的，所以也欢迎收藏本文，方便以后碰到问题方便处理。
同样使用 WPJAM Basic 出现问题之后，也不要惊慌失措，也不要直接来说出问题了，然后没有任何细节，这样谁也帮不了你，毕竟程序员也是凡人，不是神。
一般建议按照这里的方法先自己解决一遍，最后不行，只要给到相关的错误的 log（特别关注一下前面关于如何生成 log 的部分），我们都是可以帮忙定位到问题，然后解决的。
如果你使用的主机造成的问题，建议切换到阿里云和腾讯云，还是推荐使用我的链接，给我赚点佣金，才有更大动力写教程。