Wordpress: Отлов ошибок при разработке плагинов

Автор: Administrator

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

Приступим ...

Перейдите в каталог плагинов WordPress: wp-content/plugins Создайте новую директорию для плагина под названием nav-menu-filter Зайдите в директорию плагина и создайте php-файл: nav-menu-filter.php Откройте ваш новый файл в текстовом редакторе и добавьте необходимый комментарий-заголовок:
<?php /* Plugin Name: Nav Menu Filter Plugin URI: Description: Прячет пункты меню от не зарегистрированных пользователей Version: 1.0 Author: Somebody Author URI: http://xxxxxx.xx/ License: GPLv2 */
Добавьте следующую строку кода, что бы зарегистрировать callback-функцию, которая выполнится когда WordPress подготавливает данные меню навигации для отображения на странице:
add_filter( 'wp_nav_menu_objects', 'new_nav_menu_items', 10, 2 );
Добавьте следующий кусок кода, реализующий функцию new_nav_menu_items. Заметьте, что я нарочно допустил ошибку в ключевом слове functio:
functio new_nav_menu_items( $sorted_menu_items, $args ) { echo '<pre>' . print_r( $sorted_menu_items, 1 ) . '<pre>'; return $sorted_menu_items; }
Сохраняем файл
Идем в админку нашего сайта во вкладку Plugins
Находим наш плагин в списке и активируем его.

WordPress покажет сообщение о фатальной ошибке, указывающее, что плагин не может быть активирован т.к. была найдена синтаксическая ошибка. Он также указывает точное имя файла и строку где произошла ошибка, помогая сузить облать поиска проблемы.
Перейдите обратно в редактор кода и исправьте слово function и сохраните файл.
Перейдите в админку и попробуйте активировать плагин еще раз. Теперь все должно получиться.
Вернитесь в редактор и попробуйте удалить последнюю букву в слове function, создав тем самым опять ту же самую синтаксическую ошибку.
Обновите страницу сайта. Теперь вы увидите, что весь контент исчез, а браузер отображает пустую страницу с сообщением об ошибке, подобной той, что мы только что видели.
Исправьте ошибку в коде, сохраните файл. Сайт придет в норму.
В панели WordPress, перейдите на вкладку Внешний вид | меню Для экспериментов можно взять любое меню, отображающееся в шаблоне текущей темы и поместить в него ссылку (простого типа, где надо указывать адрес в ручную). Назовите её Private Area и задайте ей адрес /privatearea
Сохраняем изменения нажав на кнопку Сохранить меню
Обновите страницу сайта. Сейчас мы увидим много распечатанной информации, прежде чем сможем увидеть далеко внизу наше меню. Этот вывод генерируется с помощью функции print_r и призван помочь нам понять, как организованы входные данные, переданные нашей callback-функции. Как только мы разберемся со структурой этих данных, мы сможем правильно внести изменения в эту информацию.

Замените вызов функции print_r внутри нашей callback-функции фильтра следующим кодом:


// Проверяем зарегистрирован ли юзер:
if ( is_user_logged_in() == FALSE ) {
    // Цикл по всем полученным элементам:
    foreach ( $sorted_menu_items as $key => $sorted_menu_item ) {
        // Проверяем на совпадение название элемента меню
        if ( $sorted_menu_item->title == "Private Area" ) {
            // Если совпало - просто удаляем элемент
            unset( $sorted_menu_items[ $key ] );
        }
    }
}

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

Как это работает ...

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

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

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

И последнее, но не менее важное: реализация callback-функции фильтра использует API WordPress функцию is_user_logged_in, чтобы понять, зарегистрирован ли юзер или нет, и показывать ли ему приватную ссылку или нет.

В дополнение к рассмотренным методам отладки, WordPress предлагает ряд встроенных инструментов для облегчения поиска неисправностей плагинов. Файл wp-config.php, расположенный в корне файловой структуры WordPress, в основном использоваться для хранения данных о конфигурации сайта, но он также может быть использован, чтобы установить в нем разные константы отладки.

Первая из них WP_DEBUG, если она имеет значение TRUE то при работе сайта будут отображаться все PHP ошибки, предупреждения и уведомления в верхней части страниц. Собственно это есть режим отладки.


 define ('WP_DEBUG', TRUE);

Для предотвращения отладочных сообщений от воздействия на фронтенд сайта, вы можете скачать полезный плагин называется Debug Bar для сбора сообщений и отображения их в админке.

Другие полезные константы отладки, которые могут быть активированы в файле WP-config.php следующие:

WP_DEBUG_LOG: При значении TRUE включает сохранение всех отладочных сообщений в файл с именем debug.log в директории wp-content для последующего анализа.

WP_DEBUG_DISPLAY: Определяет, должны ли сообщения об ошибках отображаться на экране.

SAVEQUERIES: Сохранение всех запросов к базе данных в переменной, которая может быть показана в футере шаблона см. дополнительную информацию

Предыдущие статьи этого цикла:

Wordpress: Отлов ошибок при разработке плагинов

Добавить комментарий