Белый экран смерти WordPress: руководство по восстановлению

WordPress, как MacOS и даже Windows сейчас, имеет печально известный «Белый экран смерти» или сокращенно «WSOD». WSOD появляется, когда что-то идет не так. Вы сталкиваетесь с пустым или почти пустым белым экраном по неизвестным причинам. Что теперь?

Что такое белый экран смерти WordPress (WSOD)?

Вы вряд ли столкнетесь с «белым экраном смерти» (WSOD) на сайте WordPress в обычных условиях. Это просто пустой белый экран, который появляется вместо общедоступного внешнего или внутреннего интерфейса сайта WordPress. Это означает, что WordPress потерпел крах и не загружается должным образом.

Почему? Что пошло не так?

С тех пор как в мае 2019 года был выпущен WordPress 5.2, в WordPress появился режим восстановления, чтобы защитить вас от WSOD. Без режима восстановления проблемы совместимости приводили бы к большому количеству WSOD и разочарованию пользователей WordPress. Если на вашем сервере используется версия PHP или MySQL, которая не поддерживается подключаемым модулем, темой или расширением, которые вы устанавливаете, вместо того, чтобы ломать свой сайт, вы получите режим восстановления. Сегодня ошибка PHP Out-of-Memory (OOM), вероятно, является наиболее распространенным оставшимся сценарием, который обходит защиту WSOD, оставляя вас с полностью пустым экраном.

Я связался с основным участником WordPress Мариусом Дженсеном, чтобы узнать, что еще может вызвать настоящий WSOD в наши дни. Мариус является автором плагина Site Health (теперь Health Check and Troubleshooting), концепция и функции которого в конечном итоге вошли в ядро ​​WordPress. (Вот как мы получили режим восстановления и другие средства защиты.) Мариус подтвердил, что единственный способ вызвать сбой WordPress с полностью пустым экраном — это прервать поток выполнения PHP, чтобы обработчик фатальных ошибок не мог работать должным образом. Этого можно добиться, разорвав соединение между PHP и вашим HTTP-сервером. Вы не получите никаких отзывов об устранении неполадок на экране. Это было бы неприятно, но если вы просто работаете внутри WordPress, устанавливаете и настраиваете плагины, это вряд ли произойдет.

Означает ли белый экран смерти, что WordPress был взломан?

Нет, WSOD не означает, что вас достали плохие парни. Однако в редких случаях это может быть побочным эффектом нарушения безопасности. Если вы считаете, что хакеры взломали ваш сайт, обратитесь к руководству Кэти Зант «Как очистить взломанный сайт 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 будут отображаться сообщения с похожими формулировками, например, «На сайте возникли технические проблемы».

Если вы перейдете по URL-адресу бэкенда /wp-admin , также появится уведомление о необходимости проверить учетную запись электронной почты администратора для получения дополнительной информации:

В других случаях вы можете увидеть белый экран с жирным текстом, описывающим «Внутреннюю ошибку сервера» с каким-то объяснением и руководством по исправлению вашего сайта.

Добро пожаловать в восстановление

Это режим восстановления. WordPress пытается помочь вам снова встать на ноги.

Первое, что нужно сделать, это проверить адрес электронной почты, связанный с вашей учетной записью администратора WordPress. WordPress пытается выявить фатальные ошибки PHP во всем выполняемом коде.

Если возможно, WordPress «приостановит» работу плагина или другого кода, который работает со сбоями. WordPress будет препятствовать выполнению плохого кода. Затем он сообщит подробности администраторам по электронной почте.

В письме о режиме восстановления вы найдете инструкции и временную ссылку для входа в WordPress в режиме восстановления. (Эта ссылка действительна в течение 24 часов. После этого будет отправлена ​​новая, если на сайте все еще возникает критическая ошибка.)

СОВЕТ ПРОФЕССИОНАЛА: Если вы не получили сообщение электронной почты о режиме восстановления, вы все равно сможете войти в WordPress в режиме восстановления, добавив следующий адрес к URL-адресу вашего базового сайта, когда вы вошли в систему как администратор: /wp-login.php?action=entered_recovery_mode .

У вас есть возможность продолжить расследование. Если режим восстановления определил конкретный плагин как причину вашего WSOD, деактивируйте его. Это сделает ваш сайт доступным для всех. Затем вы можете исследовать любые известные проблемы для этого плагина. Проверьте, есть ли для него обновление. Обратитесь к людям, ответственным за его обслуживание.

Не все белые экраны смерти одинаковы в WordPress

В некоторых исключительных случаях что-то пошло не так в WordPress или в вашей серверной среде. Процесс обновления или установки мог застопориться, в результате чего ваш сайт застрял в режиме обслуживания. Вы, ваш хостинг-провайдер или установленный вами плагин могли изменить файлы php.ini или .htaccess с неожиданными результатами. Ваша существующая среда может не поддерживать требования недавно установленного подключаемого модуля.

Режим восстановления WordPress не может справиться с такими ситуациями, но он будет отображать видимые сообщения об ошибках на белом экране. Внешний интерфейс вашего сайта может быть недоступен, но экран входа администратора и внутренний интерфейс могут работать нормально.

Это не настоящие ситуации WSOD, но они так же раздражают. Обычно их вызывает одно из следующих состояний:

1. Вы застряли в режиме обслуживания

При обновлении ядра WordPress, плагинов или тем WordPress переходит в «Режим обслуживания». При просмотре любой части сайта отображается серый экран с белым окном сообщения, в котором говорится:

Иногда это не проясняется за минуту, но качественный хостинг WordPress заметит и исправит это с помощью автоматизированного процесса. Если вы подождали несколько минут без каких-либо изменений, вы можете выйти из режима обслуживания, удалив файл .maintenance в корневой папке веб-сайта/приложения, где установлен WordPress. (Чтобы увидеть его, вам может понадобиться включить просмотр «невидимых» файлов, в названии которых стоит точка.)

Если файл .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
max_input_vars = 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');

Значения памяти и времени в этих параметрах являются лишь рекомендациями. Чтобы убедиться, что они работают, и проверить их текущие значения, используйте инструмент Site Health в интерфейсе администратора WordPress.

Наряду с режимом восстановления в WordPress 5.2 появился инструмент Site Health. Это очень полезно для диагностики проблем и получения технической информации о настройках вашего сайта и серверной среде. Найдите его в меню администратора в разделе «Инструменты» > «Здоровье сайта». Вы также можете воспользоваться расширенными функциями плагина Health Check and Troubleshooting для WordPress.

3. PHP не хватает памяти

PHP — это серверный язык сценариев, на котором основано ядро ​​WordPress. WSOD появляется, если для PHP недостаточно памяти для запуска WordPress и ваших активных плагинов. Вы можете увидеть это в сообщении об ошибке или в журнале.

В зависимости от вашего плана хостинга вы можете увеличить лимит памяти PHP для всех приложений на вашем сервере или для конкретного экземпляра WordPress. Если вы не знаете, что делать, обратитесь за помощью в службу технической поддержки вашего хоста.

wp-config.php

Как правило, добавление следующего параметра в ваш файл wp-config.php в вашей папке WordPress установит лимит памяти внешнего интерфейса для WordPress на 256 МБ в этом примере:

 определить('WP_MEMORY_LIMIT', '256M');

От 128 до 256 МБ должно быть более чем достаточно. Вы также можете определить максимальную или внутреннюю память, выделенную для PHP (256 МБ и в следующем примере), добавив следующую строку в wp-config.php :

 определить('WP_MAX_MEMORY_LIMIT', '256M');

Второе число — это максимальное ограничение памяти, определяющее общую память, доступную PHP для себя. Первое число — это память для WordPress, работающего в пределах этого большего ограничения PHP. Максимальный предел памяти PHP должен быть равен или превышать предел памяти приложения WordPress.

php.ini

Другой способ определить максимальное ограничение памяти PHP — это настройка в файле php.ini , расположенном в папке WordPress:

 memory_limit = 256M

Убедитесь, что в начале строки нет точки с запятой! И обратите внимание, php.ini повлияет только на экземпляр WordPress (или любого другого PHP-приложения), работающего в папке или в папке, в которой находится файл php.ini . Если у вас есть доступ к вашему серверу или корневому веб-сайту, файл php.ini , расположенный там, будет управлять параметрами окружения для всех PHP-приложений, если только у них нет собственного файла php.ini , определяющего другие условия.

.htaccess

Третий способ определить лимит памяти PHP — через файл .htaccess в папке WordPress, если вы используете Apache или Litespeed в качестве HTTP-сервера. Как и в приведенных выше примерах, .htaccess должен иметь такую ​​раскомментированную строку, чтобы установить максимальное ограничение PHP в 256 МБ:

 php_value memory_limit 256M

Ошибки в синтаксисе настроек приложения и сервера в wp-config.php , php.ini и .htaccess также могут вызвать WSOD. Возможно, вам придется вручную исправить или заменить их исходными значениями по умолчанию, если они нарушают работу вашего сайта. Если вы используете веб-сервер Apache или Litespeed, файл .htaccess , управляющий их работой, может быть изменен многими плагинами WordPress. Ошибки, внесенные в любой из этих файлов, могут вызвать WSOD и вывести из строя ваш сайт.

4. Ваш HTTP-сервер дает сбой

HTTP (или его зашифрованная, безопасная форма HTTPS) — это протокол передачи гипертекста, который превращает веб-сервер в веб-сервер. Это то, как серверы обслуживают веб-страницы (HTTP-документы) клиентам (например, браузерам) по запросу.

Обычно используемые HTTP-серверы для сайтов WordPress — это Apache, Litespeed и NGINX. Их экраны ошибок выглядят немного по-разному и могут различаться способами их отображения браузерами, но все они сообщают об одних и тех же кодах ошибок HTTP.

Ошибка HTTP 500, также известная как внутренняя ошибка сервера, указывает на непредвиденную проблему с вашим HTTP-сервером, которая не позволяет ему выполнять HTTP-запросы. Другие коды ошибок сервера 5xx, особенно 502 (плохой шлюз), 503 (служба недоступна) и 504 (время ожидания шлюза), указывают на то, что ваш сервер перегружен или недоступен. Внутренняя ошибка 500 — это универсальное средство для сбоев на сервере, из-за которых он не может вернуть запрошенную страницу/документ.

Ваш браузер может по-своему интерпретировать экраны ошибок HTTP и отображать собственные специальные коды ошибок. Google Chrome (и другие браузеры на основе Chromium) перечисляет и объясняет все свои собственные коды ошибок внутри, если вы переходите к chrome://network-errors/ в адресной строке при использовании Chrome.

Проблемы на стороне сервера

Обычно используемое программное обеспечение HTTP-сервера для сайтов WordPress включает 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. Узнайте больше о .htaccess на WordPress.org.

Проблемы на стороне клиента

Ошибки HTTP 500 также могут быть вызваны на стороне клиента (в вашем браузере) другими причинами:

5. Неверные настройки браузера.
6. Поврежденный кеш.
7. Поврежденные файлы JavaScript, которые запускаются в вашем браузере.
8. Проблемы с подключением к Интернету.

Попробуйте загрузить свой сайт в другом браузере, чтобы устранить проблему с текущим браузером. Если у вас есть проблема с браузером, попробуйте сбросить его настройки до значений по умолчанию. Отключите все расширения браузера или плагины, которые вы установили, чтобы проверить, плохо ли они взаимодействуют с вашим сайтом.

Если ваша проблема связана с плохими файлами кеша, некэшированная административная область WordPress может быть вам доступна. Если вы все еще можете войти в интерфейс администратора WordPress, вы можете использовать там переключатели очистки кеша или попробовать дополнительные шаги по устранению неполадок, описанные ниже.

Также возможно, что ошибка HTTP 500 может быть вызвана проблемой с базой данных, проблемой с плагином или темой на сайте WordPress или проблемой с самим WordPress.

Чтобы устранить ошибку HTTP 500, вы должны включить ведение журнала ошибок для вашего HTTP-сервера и PHP. Затем проверьте, какие ошибки появляются в обоих. Вы также можете проверить и, возможно, увеличить лимит памяти PHP, деактивировать плагины и переключиться на тему по умолчанию, чтобы увидеть, приведет ли какое-либо из этих действий к резервному копированию вашего сайта.

Ниже мы рассмотрим эти шаги более подробно. Если следование им не устраняет ошибку 500, обратитесь в службу поддержки вашего веб-хостинга для получения дополнительной помощи.

Когда WordPress действительно мертв

Если вы получаете полностью белый экран на каждой передней и задней страницах вашего сайта WordPress без каких-либо видимых сообщений об ошибках, это полный опыт WSOD. Вы можете получить некоторые сообщения об ошибках и диагностическую информацию, если знаете, как получить доступ к журналам ошибок PHP и журналам HTTP-сервера. Включение отладки PHP для WordPress — еще один вариант. Ваш хост может иметь некоторые инструменты, чтобы сделать отладку более доступной для вас. Но если это не так, вы можете просто просмотреть этот список лекарств от распространенного WSOD, пока не найдете свое решение.

Основной контрольный список для устранения неполадок и исправления белого экрана смерти WordPress

Чтобы исправить белый экран смерти WordPress, выполните следующие шаги, чтобы найти решение. Они организованы в порядке наиболее распространенных причин WSOD, с которыми я столкнулся, но вы можете попробовать их в любом порядке.

Имеет смысл отдавать приоритет решениям, которые кажутся наиболее подходящими для вашей конкретной ситуации.

Шаг регистрации ошибок и отладки (№ 2) является наиболее техническим, но он тщательный и всегда расскажет вам, что вызывает завершение работы WordPress.

Я предоставил ссылки на несколько бесплатных плагинов, которые могут быть полезными инструментами диагностики и восстановления. Вы также можете найти iThemes Security особенно полезным для его функции сканирования и восстановления базы данных, а также для обнаружения изменений файлов. В нем даже есть серверные инструменты для более глубокого изучения настроек и возможностей вашего сервера.

В крайнем случае, хорошая недавняя резервная копия вернет ваш сайт в онлайн в его последнем известном хорошем состоянии. Backup Buddy — лучший плагин для этой роли.

Очистите кеш браузера и файлы cookie

Кэшированные страницы вашего сайта в вашем браузере и на вашем сервере могут показывать вам нечто иное, чем то, что происходит на самом деле. Давайте удостоверимся, что вы видите, что WordPress показывает новым посетителям вашего сайта.

Во-первых, очистите кеш браузера и файлы cookie. Это завершит ваш пользовательский сеанс, если вы вошли в WordPress или любой другой сайт, поэтому вы смотрите на него как на любого другого посетителя.

Затем используйте свою панель хостинга и администратора WordPress (если он доступен), чтобы очистить любое кэширование на стороне сервера, которое создает ваш хост и плагины кэширования WordPress. Попробуйте отключить все кеширование вашего сайта и сервера. Выполните жесткое обновление в браузере. Если это устранит проблему, проблема может заключаться в том, что у вас активированы настройки кэша, которые не работают в вашей системе. С помощью процесса исключения вы можете определить, какие из них работают, а какие нет.

2. Ищите ошибки PHP

PHP-код в ядре WordPress, темах или плагинах может привести к фатальной ошибке, которая заставит WordPress испустить дух с белым экраном смерти.

Чтобы получить больше информации о фатальных ошибках PHP и их причинах, вы можете включить отчеты об ошибках PHP и отправить их на экран, в файл журнала или и то, и другое. Фатальные ошибки, скорее всего, укажут на источник WSOD.

Как веб-приложение на основе PHP, WordPress имеет собственную систему диагностических отчетов для отладки, которая помогает вам использовать функции регистрации ошибок PHP. Чтобы включить его и управлять им, убедитесь, что в wp-config.php есть строка, которая гласит:

 определить('WP_DEBUG', правда);

Возможно, вам придется добавить его или изменить значение с false на true. Это говорит WordPress включить отладку PHP.

Вы также можете воспользоваться ярлыком, установив и активировав плагин WP Debugging. Он включит отладку PHP для WordPress без необходимости самостоятельно изменять 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 . В начале этой строки не должно быть точки с запятой; что делает его комментарием, а не активной настройкой. Обратите внимание, что вы получите каждую ошибку PHP, предупреждение и уведомление, если вы используете E_ALL . Используйте другое значение, например E_ERROR , чтобы регистрировать только фатальные ошибки времени выполнения, которые приводят к сбою WordPress.

3. Проверьте наличие конфликтов тем и плагинов

Отладка ошибок PHP, как описано в предыдущем шаге, должна указать вам на чистую тему или файл плагина в качестве источника вашего WSOD. Вы также можете приблизиться к этому с помощью менее технического подхода к процессу устранения.

Темы устранения неполадок

Белый экран смерти часто возникает из-за конфликтов между темами и/или плагинами WordPress. Чтобы определить источник(и) конфликта, вы можете попробовать деактивировать все свои плагины и переключиться на текущие, немодифицированные пакеты тем по умолчанию с ядром WordPress, такие как Twenty Twenty-Three.

Начните с темы — ее проще всего протестировать. Если при переключении вашей активной темы на заведомо исправную немодифицированную тему по умолчанию ваш сайт снова работает, вы знаете, что проблема заключается в теме, которую вы использовали.

Взгляните на файл functions.php вашей темы, если он есть. Если вы недавно изменили его, это, вероятно, источник вашего горя. В файл functions.php добавляется пользовательский функциональный код для использования с темой при ее активации. Плохой код и синтаксические ошибки здесь дадут вам WSOD.

Устранение неполадок с плагинами

Вы можете деактивировать плагины без доступа к администратору WordPress через командную строку/SSH или SFTP, просто временно переместив папки плагинов из папки /wp-content/plugins/ . Моя практика заключается в создании подпапки плагинов с именем «A», чтобы она отображалась первой в отсортированном по алфавиту каталоге /plugins . Затем я перемещаю все остальные папки плагинов в «A».

Как только вы это сделаете, перезагрузите свой сайт. WordPress будет вести себя так, как будто все плагины исчезли. Они все еще установлены, но деактивированы. Если «Белый экран смерти» исчезнет, ​​вы можете попробовать повторно активировать свои плагины и тему один за другим, каждый раз обновляя домашнюю страницу, чтобы увидеть, какой из них вызывает сбой вашего сайта.

Meks Quick Plugin Disabler — это удобный инструмент, который быстро отключает все активные плагины, а затем повторно включает их из панели администратора WordPress по вашей команде.

4. Восстановить поврежденные файлы ядра

Ваш WSOD может быть следствием повреждения основных файлов WordPress. Хотя это маловероятно, можно просто быстро переустановить последнюю версию WordPress одним щелчком мыши в области обновлений панели управления WordPress. Это не повредит ни одному из ваших плагинов, тем или существующему контенту, поэтому это хороший и простой способ убедиться, что ваши основные файлы в порядке.

Если ни один из вышеперечисленных шагов не помог, WSOD может быть вызван проблемой с вашей серверной средой, которая находится за пределами вашей досягаемости. В этом случае вам, возможно, придется обратиться за помощью к вашему хостинг-провайдеру. В крайнем случае вы также можете откатить свой сайт до «последнего удачного» состояния, восстановив резервную копию.

Как предотвратить WSOD — советы владельцам сайтов WordPress и разработчикам

WordPress работал нормально — и вдруг у вас появился Белый Экран Смерти!

Вероятно, это потому, что ВЫ изменили что-то критичное для функционирования WordPress.

Если вы используете надежную управляемую учетную запись хостинга WordPress с Liquid Web или Nexcess, которая правильно настроена и имеет достаточно ресурсов для того, что вы с ней делаете, 99% способов, которыми вы можете сломать WordPress с помощью WSOD, можно избежать.

Проблема в том, что владельцы сайтов не избегают этой практики!

Чего не делать

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 Security Pro

Дэн Кнаусс

Дэн Кнаусс — специалист по техническому содержанию StellarWP. Он был писателем, учителем и фрилансером, работающим с открытым исходным кодом с конца 1990-х годов и с WordPress с 2004 года.