Как исправить белый «экран смерти» WordPress? Как исправить ошибку в WordPress Белый Экран

Всем привет. Последнее время просто сыпятся вопросы от пользователей по поводу белого экрана смерти wordpress. Замучился каждому отвечать и решил написать небольшую статью.

Главная цель этой статьи показать вам что нужно делать если у вас появился белый экран, а также рассказать как легко и просто включить вывод ошибок в wordpress .

Навигация по странице:

Белый экран wordpress

Проблема, когда пользователь видит белый экран в wordpress вместо своего сайта не новая, и обсуждаема много и много раз. Основной причиной его возникновения есть критические ошибки в php, но так как в 90% случаях ошибки на сайте отключены, то вместо ошибки мы видим белый экран.

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

И вы гарантировано увидите белый экран wordpress.

WordPress белый экран в админке

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

Сделать белый экран в админке wordpress очень просто, например можно править файл темы functions.php , допустить в коде ошибку (забыть закрыть скобку или установить лишнею) и сохранить изменения. Вуаля, ошибка wordpress белый экран в админке нам обеспечена. Кстати, такую детскую ошибку невозможно вылечить без доступа к сайту по фтп или файлового редактора из хостинг панели 🙂

Что делать если на сайте wordpress белый экран?

Нужно включить ошибки и диагностировать проблему.

Как включить вывод ошибок wordpress

Следуйте пошаговой инструкции, нажимая на цифры 1 2 3 в переключателю ниже:

Как избавится от ошибок wordpress

Предположим вы включили вывод ошибок wordpress, ваш белый экран стал экраном с текстом ошибок, что делаем дальше?

Нам нужно попытаться исключить ошибку!!!

Смотрим текст ошибки, там будет указан путь к файлу где возникла ошибка и строка, например я лишний раз закрыл } скобку в файле functions.php, за это получаю такую ошибку:

Parse error: syntax error, unexpected "}" in /home/c/site/site.bget.ru/public_html/wp-content/themes/twentyfifteen/functions.php on line 2

путь к файлу у нас есть, строка тоже идем и исправляем ошибку.

Конечно это самый простой пример, бывают ситуации намного хуже. Например установили вы кривой плагин и он заблокировал вам весь сайт вместе с админкой, что делать как отключить?

Довольно просто, из ошибки смотрим как называется плагин, допустим "wp-plagin-bag-ru" заходим на фтп и идем в папку "wp-content" -> "plugins" находим там такое имя директории "wp-plagin-bag-ru" и переименовываем ее во что угодно, например в "wp-plagin-bag-ru__".

Если это был вредоносный плагин то мы его отключили и сайт должен начать работать в штатном режиме.

Разумеется приводить примеры можно очень долго и все равно, найдется такой уникальный случай, который я не описал. Для таких случаев у нас на сайте есть раздел Вопрос/ответ, где вы можете написать ошибку, которую выдает ваш сайт, и мы с радостью попробуем вам помочь. Также, можно описать проблему в комментариях и мы ответим вам максимально оперативно.

Большой интернет-магазин созданный на основе WordPress и плагина WooCommerce. Со слов клиента: "Работал он работал, а сегодня стал заходить в админку, а там ничего нет. Не входит короче." Ну когда, не входит, это реально проблема, а с админкой что, не удержался, тролить это весело. Не подумай, я такого клиенту не сказал и тебе не советую их тролить, знай, что они по определению не понимают твоего и моего юмора. В общем беда, вместо удобной и красивой панели администратора CMS WordPress у нас белый экран смерти (это не я придумал, его так называют в сети).

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

Ну, Вы уже догадались, что я сделал первым делом. Именно, так, я залез в конфиг и включил режим отладки. Делается это просто, лезем по FTP в корень, или где там спрятан файл wp-config.php и открываем его для редактирования. Там есть специальная строка, которая задаёт, необходимую константу для CMS WordPress, собственно, в ней то и достаточно изменить false на true . И вот режим отладки включился.

Ну если у Вас там, по каким-либо причинам, нет такой строчки, не стесняйтесь допишите её сами. Можете еще и такие строчки туда добавить:

Define("WP_DEBUG_DISPLAY", false); define("WP_DEBUG_LOG", true);

Тогда у Вас будет создан файл debug.log в папочке wp-content и туда будут писаться все выявленные ошибки. Как Вы уже догадались, первая строка отключает показа ошибок в браузере, а вторая включает запись выше означенного файла лога ошибок.

Кстати, кто не знал, теперь знайте, движитель WordPress, это мудрый движитель, он легко позволяет немного спрятать свой файл конфигурации. По умолчанию wp- config. php находится в корне, но его можно переместить на уровень выше, то есть убрать совсем из общедоступной папки. Например, корень залегания Вашего сайта имеет путь <доменное имя сайта>/ public_ html/. Берём и переносим файл из public_ html в папку на уровень выше, то есть <доменное имя сайта>. Дальше хитрый движитель WordPress сделает всё сам. В смысле, не найдя файл в корне, он, не слишком удивившись данному факту заглянет на уровень выше, куда нет публичного доступа из сети, и о чудо, он найдёт там, файл, который мы туда благополучно спрятали.

Большая информационная сноска, ну не мог я смолчать, согласись, это же, полезная информация! Ладно, продолжим, данные действия нечего не дали, ошибок не было видать, так сказать, белый экран смерти WordPress, это не я его так окрестил, его так назвали на бескрайних просторах Интернет, был незыблем и всё так же символизировал собой, фразу "Вся жизнь - тлен ".

Ну, я-то ведь жизнерадостный иди… человек, да именно так, решил зайти, с другой стороны, глянуть логи ошибок через хостинг. Да, да, на хостинге есть такая фишечка. Собственно, включил логирование всех ошибок, пару раз обновил белый экран и полез смотреть, что там интересного мне понаписали в логах. Каково же было моё удивление, что и там тоже было пусто, то есть, реально, совсем пусто, как говорится ни одна муха не сидела.

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

Практика устранения белого экрана WordPress

Нормальные способы не помогли, я перешел к ненормальным. А, именно взял и добавил циферку 1 в названии папки plugins, расположенной в папке wp-content. Почему так, ну Вы не забыли, мы как бы в панель Администратора пытаемся попасть. Вот, а отключить сразу все плагины, можно тремя способами, через панель администратора, тем какой я использовал (он быстрее и проще) и третий через phpMyAdmin .

Пару слов о третьем способе, да, да, опять не могу удержаться и должен рассказать. Но это для Вас! Не важно, что Вы им не воспользуетесь, зато будете знать. Заходим в БД (о да, это она бро, та самая база данных, с которой ты не хотел связываться, и которая тебя, всегда пугала тремя буквами SQL) и там вводим, на вкладке SQL запросов, такую строку:

UPDATE wp_options SET option_value = "" WHERE option_name = "active_plugins";

Или же заходим в таблицу wp_option ищем там в столбце option_name , строку active_plugins . И вот уже в этой строке стираем содержимое ячейки option_value. Рекомендую тебе проделать это ручками, без использования SQL запроса, там тебе откроются великие тайны JSON, а именно в нём хитрый WordPress хранит данные в выше означенной ячейке своей БД. Чисто из любопытства на посмотреть, если нет желания, то используй SQL запрос.

В общем, я отключил плагины и ничего, опять белый экран, да и сайт еще перестал работать. Да, да, так бывает, когда, вдруг, отрубить все плагины, разом. Но, я, как ты помнишь, воспользовался вторым способом, и путём нехитрой манипуляции, снова запустил все плагины. И о, чудо, сайт снова заработал, но не админ панель, то есть мы пришли к тому, с чего и начинали. Белый экран и его сакраментальное "Вся жизнь - тлен". Но, как ты помнишь, я-то ведь жизнерадостный иди… человек. Решил не копаться дальше, можно было бы аккуратно дописать немного кода в файл admin.php и всё-таки найти ту заразу, которая рождала белый экран. И я бы этим и занялся, но клиент, сообщил, что белый экран появился после того, как сайт перенесли на новый хостинг, где он благополучно заработал и всё работало пока антивирус на хостинге (кстати, это был beget , да у них там бесплатный антивирус, мне тоже нравиться, там вообще много хорошего, рекомендую его) не сообщил, что найден вирус и надо полечить путём удаления вредоносного кода из файла (с какого хостинга перенесли сайт, по понятным причинам умолчу, скажу что он большой и солидный, и очень известный). Ну, клиент, естественно согласился и код был удалён. Но проблема всех антивирусов, что они удаляют не только вредоносный код, но и цепляют код который нужен, но был испорчен внедренным кодом.

В свете новой информации, я перестал танцевать с бубном и распевать шаманские напевы, а то уже домашние, стали косо на меня поглядывать и бросали подозрительные взгляды на телефон. И решил использовать, образно выражаясь дубину, ну это исконно русский способ ремонта тонкой электроники. А, именно, переустановить движитель WordPress, но не простым и доступным, а ручным способом, да, мы ведь, хоть и используем дубину, но клиент не обрадуется если мы "Жахнем и весь мир в труху " (с) ДМБ.

Кстати, дружище, я надеюсь ты уже на этапе между принял заказ от клиента и начал копаться в файлах сайта, потрудился сделать БЭКАП файлов сайта и его БД, ну или заставил сделать это клиента. Если нет, ну я не хочу говорить плохих слов, просто сделай это сейчас! И в будущем, чтобы ты не делал с сайтом клиента, всегда первым делом делай бэкап. Меняешь код в файле, сохрани первоначальный файл, просто переименуй его, добавь префикс _ old или еще чего-нибудь, это у тебя должно быть на уровне неосознанного рефлекса.

Но вернемся к нашему ручному обновлению WordPress. Тут всё просто идём сюда оф. сайт WordPress и скачиваем дистрибутив, нашего движителя. Распаковываем полученный архив у себя на компьютере. Затем открываем по FTP файлы нашего сайта (я пользуюсь WinSCP, ранее использовал FileZilla) и там удаляем два каталога это wp-admin и wp-includes . Остальное не трогаем, помни, наша задача не показать насколько мы круты, а сделать то, что желает клиент, он ведь всегда прав, как бы. И далее копируем всё из распакованного дистрибутива, при этом соглашаясь заменить все чего там он пожелает поменять, поверь он знает, что и где поменять, так что пусть меняет. Всё что останется, это зайти в панель администратора и проверить всё ли там путём. Да, админ панель по любому заработает после такого непотребства, которое мы с тобой свершили. Цель достигнута, добра тебе и процветания!

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

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

Белый экран смерти (WSOD) практически всегда связан с ошибками в коде PHP или исчерпанием доступной памяти. Первое, что нужно сделать, это определить, работает или нет панель администратора. Если фронтэнд сайта не отображается, но при этом панель администратора работает, то в таком случае проблема, скорее всего, вызвана поврежденной темой или плагином.

Отключаем плагины и темы

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

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

Включаем режим отладки

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

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

Чтобы включить режим отладки, вам нужно открыть файл wp-config.php вашей сборки WordPress. В нем должна быть следующая строка:

Define("WP_DEBUG", false)

Вам нужно заменить false на 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/my-test-plugin/my-test-plugin.php on line 38

Как вы можете видеть, проблему вызвала строка 38 плагина, который называется «my-test-plugin». Отключаем этот плагин, и все должно заработать.

Совет: если у вас имеется доступ по FTP или вы можете зайти на сервер через панель управления вашего хостинга (к примеру, cPanel), вы можете разом деактивировать все плагины, переименовав папку plugins, к примеру, в plugins.hold. Папка находится в wp-contents.

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

Увеличиваем лимиты памяти

Если вы по-прежнему видите пустую страницу или получаете сообщение о нехватке памяти, то в таком случае вам нужно выделить приложению больше памяти. Сделать это можно через файл wp-config.php в большинстве сборок, просто добавьте следующий код:

Define("WP_MEMORY_LIMIT", "64M");

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

Php_value memory_limit 64M

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

Memory_limit = 64M

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

Решаем проблемы с правами доступа к файлам

Эта причина вряд ли может привести к белому экрану смерти, однако она по-прежнему может вызывать разные проблемы.

Для WordPress действуют следующие правила:

• Файлы должны быть 664
• Папки должны быть 775
• Файл wp-config.php должен быть 660

Если у вас есть SSH-доступ к вашему серверу, вы можете применить соответствующие правила путем выполнения следующей команды, выполненной из корневой директории WordPress:

Sudo find . -type f -exec chmod 664 {} + sudo find . -type d -exec chmod 775 {} + sudo chmod 660 wp-config.php

Если вы боитесь менять что-то самостоятельно, обратитесь к своему хостингу. Они сделают это за вас. Некоторые WordPress-хостинги имеют автоматическую проверку прав доступа, которая позволяет все настроить за пару секунд.

Решаем проблемы с автоматическим обновлением

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

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

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

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

Из сегодняшнего подробного руководства, посвященного проблеме белого экрана, вы узнаете:

• Причины его появления
• Пути его устранения
• Что сделать, чтоб попрощаться с ним навсегда.

Мы пошагово рассмотрим четыре основных способа устранения "белого экрана смерти" раз и навсегда. Среди них:

1. Проверка используемых плагинов
2. Увеличение лимита памяти PHP
3. Смена используемой на данный момент темы
4. Активация debug режима

ВНИМАНИЕ! Перед внесением любых из вышеперечисленных изменений на свой сайт сделайте полный бэкап всех файлов и базы данных.

И только после этого можете переходить к выполнению первого метода.

1. Проверка плагинов

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

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

1. Перейдите в раздел Плагины .
2. Деактивируйте ранее добавленный плагин. Обычно это сразу же устраняет белый экран, и вы можете продолжить пользоваться сайтом в привычном режиме.
3. Если после этого ничего не изменилось и белый экран не исчез, то деактивируйте абсолютно все активные на данный момент плагины. Для этого в этом же разделе отметьте галочкой нужный бокс над списком плагинов, выберите в выпадающем списке функцию «Деактивировать» и сохраните изменения.

Можно, конечно же, отключать плагины один за другим и сразу же проверять состояние сайта. Но если ничего не изменилось и после деактивирования всех плагинов, то причина кроется в чем-то другом.

1. Подключитесь к серверу сайта через соединение FTP или с помощью контрольной панели и перейдите в управление файлами.
2. Перейдите в директорий сайта wp-content и переименуйте папку plugins на свое усмотрение. Например, на plugins-old .
3. Теперь, когда все плагины деактивированы, обновите сайт и скрестите пальцы, чтоб не увидеть белый экран.

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

2. Увеличение лимита памяти PHP

Редактируем файл wp-config.php

Для этого:

1. Установите соединение с сервером FTP и перейдите в корневой директорий сайта.
2. Откройте файл wp-config.php в текстовом редакторе и добавьте в него строку кода:
    define("WP_MEMORY_LIMIT ", "64M ");
   Учтите, что указанный в строке объем памяти в размере 64Мб может отличаться в зависимости от используемого вами сервера.
3. Сохраните изменения и обновите сайт. Если все хорошо, то вас можно поздравить. Если нет, продолжайте искать проблему дальше.

Редактируем файл php.ini

1. Снова соединитесь с сервером FTP и перейдите к корневой директорий вашего сайта.
2. Получив доступ к файлу, добавьте в него следующую строку кода:
    memory_limit = 64M ;
   Если же у вас нет к нему доступа, то вы можете создать его в корневой директории вашего сайта на WordPress.
3. Сохраните все изменения и обновите сайт. Имейте в виду, что максимальный объем оперативной памяти, необходимый для работы скрипта сайта на WordPress – 64 Мб.

Редактируем файл .htaccess

Этот файл есть на каждом сайте на WordPress.

1. Для начала вам снова понадобится доступ к серверу FTP и корневой директории сайта.
2. Отредактируйте файл и добавьте в него строку кода:
   php_value memory_limit 64M
3. Еще раз обновите фронтенд сайта. Белый экран по прежнему перед глазами? Тогда двигаемся дальше.

3. Замена активной темы

Если у вас есть доступ к Консоли

1. Перейдите в раздел Внешний вид → Темы в админке.
2. Активируйте любую стандартную тему, например, Twenty Fourteen или Twenty Thirteen.
3. Обновите сайт. Какой результат? Ваш монитор до сих пор красуется белым полотном? Не теряйте терпения. Продолжайте искать причину дальше. Тем более что осталось еще совсем чуть-чуть.

Если у вас нет доступа к Консоли

В этом случае вам придется немного потрудиться, так как через админку все делать намного проще. Но что поделаешь, если у вас нет другого выбора.

1. Подключитесь к серверу своего сайта через FTP и проверьте, что стандартные темы WordPress загружены на сервер.
2. Теперь откройте phpMyAdmin через панель управления хостингом и перейдите к таблице wp_options в базе данных.
3. На странице параметров ищите «template » и «stylesheet ». Их названия нужно заменить согласно названию директория темы, которую вы хотите сделать активной. В нашем случае это "twentyfourteen " или "twentythirteen ".
4. Обновите сайт. Если все осталось неизменным, то не стоит отчаиваться. Осталась последняя причина, которая могла спровоцировать появление белого экрана.

4. Активация дебаг режима

Если файл wp-config.php содержит дебаг-код

1. Подключитесь к серверу через FTP и зайдите в корневую директорию сайта.
2. Откройте файл и разместите в нем строку кода:
    define("WP_DEBUG ", false);
3. Для активации дебаг-режима измените исходное значение false на true вот таким образом:
    define("WP_DEBUG ", true);
4. Обновите страницу.

Более детально ознакомиться с информацией о дебаг-режиме (отладка) можно на странице WordPress Codex .

Если файл wp-config.php не содержит дебаг-код

1. Снова потребуется подключение к серверу через FTP и доступ к корневой директории сайта WordPress.
2. Откройте файл wp-config.php и разместите строку кода со значением true:
    define("WP_DEBUG ", true);
3. Обновите страницу и во фронтенде сайта появится отладочная информация, которая поможет вам выявить причину белого экрана.

Заключение

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

Белый экран смерти (White Screen of Death – WsoD) – это хорошо документированная ошибка WordPress , которая может возникать по ряду различных причин, и которая так же раздражительна, как и ее двоюродный брат – синий экран смерти Windows. Эта ошибка является такой неприятной по причине полного отсутствия каких-либо сообщений об ошибках, что может стать кошмаром при устранении неполадок. Если вы читаете эту статью, скорее всего вы уже сталкивались с этой проблемой в тот или иной момент.

К счастью, сообщество WordPress очень изобретательно, и со временем оно обнаружило наиболее распространенные причины Белого экрана смерти.

Что вызывает Белый экран смерти:

1. Ограниченный объем памяти, установленный хостингом (чаще всего на низкобюджетном хостинге)
2. Тема, которая не поддерживает определенный плагин, или наоборот
3. Плохое качество кода темы или плагина, что вызывает ошибку при обновлении WordPress
4. Плохая совместимость между плагинами

Давайте подробнее рассмотрим каждую из этих причин и процесс их отладки.

1. Проверьте лимит памяти

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

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

Зайдите в корневую папку размещения вашего сайта (с помощью любого удобного файлового менеджера, или через панель управления хостингом) и откройте файл wp-config.php (с помощью любого удобного текстового редактора). Чтобы повысить лимит до минимально оптимального значения, добавьте в этот файл следующую строку:

Define("WP_MEMORY_LIMIT", "128M");

Кроме этого не делайте больше никаких других изменений в файле wp-config.php , если вы не хотите еще больше поломать свой сайт. Сохраните и закройте файл и проверьте, не устранена ли ошибка белого экрана на сайте.

Если ошибка не исчезла, пора перейти к следующему шагу.

1. Проверьте плагины

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

Первое, что нужно сделать – это исключить возможность неработающих плагинов вообще, и для этого мы отключим сразу все плагины. Перейдите в корневой каталог сайта, а затем зайдите в папку wp-content . Мы переименуем папку, отвечающую за все плагины на сайте – plugins , чтобы заставить WordPress считать, что на сайте совсем не используются плагины. Переименуйте эту папку произвольным образом.

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

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

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

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

1. Проверьте свою тему

Методология такая же, как и при работе с плагинами. Перейдите в корневой каталог сайта, а затем перейдите в папку wp-content . Мы переименуем папку, отвечающий за все темы на сайте – themes . Это принудительно отключит ее и активирует на сайте WordPress последнюю тему по умолчанию – Twenty Seventeen (в 2017 году). Если вы раньше удаляли темы WordPress по умолчанию, вам придется скачать тему Twenty Seventeen в папку themes .

После этого перейдите на свой сайт и посмотрите, остается ли белый экран смерти. Если проблема исчезла, значит, вероятно, существовала проблема совместимости темы и текущей версии ВордПресс.

Теперь настройка темы может стать сплошной головной болью, но возможно для начала стоит рассмотреть вопрос перехода на другую тему?

Но что делать, если ни один из этих шагов не решил проблему с БЭС? Тогда переходите к следующему шагу.

1. Проверьте свои логи

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

Желательно это делать на локальном сервере, а при невозможности этого, скорее выключайте режим отладки после коротких тестов. Для включения режима отладки откройте файл wp-config.php и добавьте следующие строки PHP кода:

Define("WP_DEBUG", true); define("WP_DEBUG_LOG", true); define("WP_DEBUG_DISPLAY", false);

Первая строка указанного кода активирует режим отладки; второй предписывает WordPress хранить логи операций в файле debug.log (в каталоге wp-content ), а последняя строка кода заставляет систему НЕ показывать ошибки на сайте, если они будут обнаружены на сайте.

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

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