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

Перейдите в файл wp-config.php и замените define('WP_DEBUG', false);
на define('WP_DEBUG', true);
. Также установите плагин Log Deprecated Notices от Andrew Nacin.

Я бы также рекомендовал ознакомиться с другой статьёй Насина: http://www.andrewnacin.com/2010/04/23/5-ways-to-debug-wordpress/

В PHP 5.4+ вы, скорее всего, столкнётесь с множеством уведомлений E_STRICT. Поместите этот gist в папку плагинов и активируйте, чтобы убрать Strict-уведомления, деактивируйте для возврата к обычному режиму работы.

Если вы видите выводимые ошибки, то x-debug — это отличное расширение PHP, которое добавляет современные трассировки стека (backtraces) в PHP.
Если вы пытаетесь разобраться в ситуации, где нет ошибок, мой любимый подход — это определение функции, которая записывает свой вывод в файл. Например, я использую plog($переменная), и это появляется в лог-файле, который я затем могу изучить. Это особенно полезно, когда вы пытаетесь выяснить, что произошло до вызова header(), или в других ситуациях, когда вы не можете выводить данные в STDOUT.

Используйте xdebug + NetBeans IDE. После правильной настройки — что довольно просто — вы сможете устанавливать точки останова в своём плагине и отслеживать значения переменных в этих точках. На мой взгляд, это лучший способ отладки плагинов или любых PHP-приложений в целом.

После экспериментов с различными IDE я остановился на старом добром Notepad++ с ультра-настроенной цветовой схемой подсветки синтаксиса.
У меня настроен макрос, который при нажатии Shift-Ctrl-X вставляет следующий код в месте расположения курсора:
echo "<pre>";
var_dump($);
echo "</pre>";
exit();
Это просто, но с этим макросом и включенным WP_DEBUG я обычно могу найти 90% своих ошибок.

Я отлаживаю по-старинке, используя error_log()
и var_dump()
. Для меня это наиболее эффективный способ. У меня есть пара обёрточных функций для обработки разных типов данных, так как логирование массивов и объектов через error_log
может быть проблемным. Также использование print_r()
может быть неудобочитаемым, если не обёрнуто в тег <pre>
. У меня есть tj_log()
для логирования ошибок и tj()
для вывода данных (который в основном отображает любой тип данных в удобном виде):
function tj( $code ) {
?>
<style>
.tj_debug { word-wrap: break-word; white-space: pre; text-align: left; position: relative; background-color: rgba(0, 0, 0, 0.8); font-size: 11px; color: #a1a1a1; margin: 10px; padding: 10px; margin: 0 auto; width: 80%; overflow: auto; -moz-box-shadow:0 10px 40px rgba(0, 0, 0, 0.75); -webkit-box-shadow:0 10px 40px rgba(0, 0, 0, 0.75); -moz-border-radius: 5px; -webkit-border-radius: 5px; text-shadow: none; }
</style>
<br /><pre class="tj_debug">
<?php
if ( is_null( $code ) || is_string($code) || is_int( $code ) || is_bool($code) || is_float( $code ) ) :
var_dump( $code );
else :
print_r( $code );
endif;
echo '</pre><br />';
}
function tj_log( $code ) {
if ( is_null( $code ) || is_string($code) || is_int( $code ) || is_bool($code) || is_float( $code ) ) :
$code = var_export( $code, true );
else :
$code = print_r( $code, true );
endif;
error_log( $code );
}
Таким образом, я просто вызываю: tj( $current_user );
или что-то подобное.

Я написал небольшой класс для создания лог-файла, который очень полезен при отладке AJAX-запросов.
http://github.com/hunk/Magic-Fields/blob/master/tools/debug.php
Вам нужно просто сделать что-то вроде:
Debug::log("Это отладочное сообщение");
Когда эта строка выполняется, сообщение будет добавлено в лог-файл, и затем вы можете использовать команду tail (если используете операционную систему в стиле Unix):
tail -f mylogfile.log
Вы также можете передавать в эту функцию массивы или объекты.
Примечание: вам нужно изменить строку 20 на путь, где вы хотите сохранять свой лог-файл.

Я использую Aptane IDE на Linux и UltraEdit на Windows, который также имеет PHP-парсер. Кроме того, я просматриваю все подсказки от xDebug с константой WP_DEBUG
, определённой в файле wp-config.php
.
Также ознакомьтесь с моей записью на эту тему и не стесняйтесь комментировать и делиться отзывами о ваших инструментах разработки.

Рекомендую ознакомиться с FirePHP. Это инструмент, который позволяет отправлять отладочную информацию в Firebug для Firefox через HTTP-заголовки, что обычно делает вывод отладочной информации более аккуратным.

Неплохой вариант: Eclipse. Близок к PhpStorm и бесплатный.

Я могу порекомендовать две IDE, которые сам активно использовал: PhpED (только для Windows) и PhpStorm+XDEBUG (Mac, Windows и Linux). Сейчас я работаю на Mac, поэтому могу использовать только последний вариант.
Обе просто потрясающие! Хорошая новость в том, что PhpStorm стоит $49 до сентября 2010 года, а после - всего $99. Если бы мне снова пришлось выбирать на Windows, я не уверен, какой вариант предпочел бы.
Честно говоря, мне кажется, что любой разработчик плагинов, не использующий один из этих двух инструментов, серьезно ограничивает себя, особенно если он относительно новичок в разработке плагинов для WordPress.

Krumo - стилизованный PHP-класс для отладки
Еще одна действительно полезная вещь - это PHP-класс "krumo". Он внедряется за 30 секунд и предоставляет простой способ отладки переменных любого типа:
- объектов,
- массивов,
- строк/чисел с плавающей точкой/целых чисел и т.д.
Дополнительно он помогает с трассировкой вызовов, показывает загруженные классы или подключенные файлы и всё это по требованию.
Плюс он БЕСПЛАТНЫЙ!
Скачать
Krumo @sourceforge

Я использую плагин за $13 под названием LogPress, который можно купить на ThemeForest, и это просто находка. С его помощью можно отлаживать всё, что связано с их плагинами и сайтом. Поддерживает логирование в консоль Firebug и многое другое. Я не могу без него жить — вот как часто я его использую.
Этот плагин, пожалуй, лучшие деньги, которые я когда-либо тратил, и он сэкономил мне бесчисленное количество часов в разработке плагинов для WordPress.

Вау, меня заминусовали за рекомендацию платного плагина, с которым у меня нет никакой связи? Это немного жестковато, не так ли?

Это не я минусую, но я не удивлён. Ты используешь слова, будто пытаешься продать этот плагин. Рекомендовать что-то — это нормально, но когда ты давишь с продажами в стиле "абсолютное божественное спасение", люди это ненавидят. Просто смягчи формулировки, и рекомендация зазвучит сама по себе.

Сначала я добавляю define('WP_DEBUG', false);
в файл wp-config.php (как советуют большинство) для локальной установки, которая является свежей копией рабочего сайта (и файлы, и данные). Это делает процесс быстрым, безопасным, изолированным, но хорошо отражает хотя бы одно место, где плагин будет реально использоваться.
Я также добавляю плагин Debug Bar вместе с некоторыми его дополнениями (например, Transients) — в зависимости от специфики ваших плагинов.
Ещё я использую дополнение Firebug для Firefox, которое отлично помогает отслеживать проблемы с HTML, CSS и JavaScript, а также разбираться в странностях вёрстки.
Для программирования я использую UltraEdit, которым пользуюсь уже более 15 лет для самого разного кода (от PHP до SQL) как на работе, так и дома. Для меня он отлично подходит, хотя многим может не хватать функционала для полноценной IDE. В нём есть подсветка синтаксиса, автодополнение, функции форматирования кода, а также множество инструментов для HTML и CSS, которые помогают избегать опечаток и подобных ошибок. В основном мне важна привычная среда — это часто упускают в погоне за новинками. Мышечная память помогает повторяемости, даже в программировании.
И, конечно, у меня обычно открыта какая-нибудь подходящая страница из кодекса в другой вкладке в качестве примера.
Все эти инструменты по-разному помогают выявлять ошибки в коде, парсинге, функционале и вёрстке, не слишком мешая самому процессу программирования. Большинство из них можно временно игнорировать или отключить, если вы экспериментируете или работаете над чем-то, что вернётесь дорабатывать позже.
Ах да, и нет ничего плохого в том, чтобы поставить хорошо расположенный echo или print_r для проверки чего-то важного (главное — не забыть их убрать, когда закончите).

Ознакомьтесь с плагином Query Monitor в сочетании с Query Monitor Extend для комплексной отладки WordPress (ошибки/замечания/строгие предупреждения PHP, запросы к базе данных, пути, константы, HTTP-запросы, транзиенты, переменные сессий, дампы переменных).
Также обратите внимание на плагины All Post Meta и Saving What для получения детальной информации о записях.

Просто перейдите на их сайт помощи: https://www.jetbrains.com/help/phpstorm/2016.2/configuring-xdebug.html
