Итак, клиент бегает и рвёт на голове волосы, на чьей история умалчивает. Сайт же, а, это, к слову сказать, интернет-магазин с ежемесячным оборотом от полутора миллионов рублей, вроде работает, но при входе в админ панель, появляется белый экран смерти и всё. Всё, это вот, реально, всё, не каких тебе интересных выкладок в консоли, ни каких тебе выводов предупреждений и сообщений об ошибках. Сам сайт сделан, как я уже написал выше на 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. Остальное не трогаем, помни, наша задача не показать насколько мы круты, а сделать то, что желает клиент, он ведь всегда прав, как бы. И далее копируем всё из распакованного дистрибутива, при этом соглашаясь заменить все чего там он пожелает поменять, поверь он знает, что и где поменять, так что пусть меняет. Всё что останется, это зайти в панель администратора и проверить всё ли там путём. Да, админ панель по любому заработает после такого непотребства, которое мы с тобой свершили. Цель достигнута, добра тебе и процветания!
