4 совета по исправлению сайта WordPress

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

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

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

Использование журнала ошибок нашего сервера

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

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

 appserver_1 | [Mon Aug 24 09:18:20.977541 2020] [php7:notice] [pid 1107] [client 172.20.0.2:34396] PHP Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>yoast/v1/get_head</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugg ing in WordPress</a> for more information. (This message was added in version 5.5.0.) in /app/.lando/wordpress/wp-includes/functions.php on line 5225, referer: http://nab5.lndo.site/wp-admin/edit.php

Журнал сообщает об уведомлении PHP, которое произошло в одном из собственных файлов WordPress ( wp-includes/functions.php ), что ничего не говорит нам о «виновнике плагина». К счастью, если вы прочитаете сообщение целиком, то увидите, что в нем описывается, что не удалось (т.е. вызов функции register_rest_route ), и дается намек на то, что может быть не так: Yoast (посмотрите, как там упоминается « yoast/v1/get_head » ?).

Журналы ошибок — это самый простой способ быстро узнать, когда что-то не так, и если да, то в чем причина ошибки. В этом конкретном примере я обнаружил, что у меня проблема с Yoast, и все, что мне нужно было сделать, это обновить плагин до последней версии.

Деактивация плагинов из панели управления WordPress

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

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

Для этого перейдите в Панель инструментов WordPress » Плагины , выберите все ваши активные плагины и массово деактивируйте их:

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

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

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

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

Сделайте резервную копию вашего списка активных плагинов

Помнишь моего друга с самого начала? Когда мы исследовали его веб-сайт, мы выполнили все предыдущие шаги и деактивировали все плагины на его веб-сайте…

…что привело к белому экрану смерти!

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

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

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

Таким образом, если «деактивация всех плагинов» заканчивается маловероятным (но не невозможным) WSOD, вы можете повторно активировать все плагины, восстановив параметр active_plugins в базе данных.

Как деактивировать плагины через FTP

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

Как вы уже знаете, плагины — это не что иное, как набор файлов. Когда вы устанавливаете новый плагин на свой сайт, его код попадает в папку WordPress wp-content/plugins . Воспользовавшись этим знанием, мы можем деактивировать плагин, «удалив» его из указанной папки.

Перейдите в cPanel вашего сервера и найдите опцию FTP:

Затем с помощью проводника файлов FTP найдите папку wp-content/plugins и найдите свой плагин:

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

Использовать тему по умолчанию

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

Если по какой-либо причине у вас нет доступа к панели инструментов WordPress, вы можете установить новую тему на свой сайт, загрузив ее по FTP ( wp-content/themes ) и изменить активную тему с помощью базы данных: просто измените template параметров и таблица stylesheet в wp_options . Например, вы можете установить оба параметра на twentytwenty , предполагая, что это тема, которую вы загрузили.

В итоге

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

А как насчет сайта моего друга? Ну, я не знаю — некоторые люди говорят, что он сменил карьеру…

Избранное изображение Олии Найды на Unsplash.