Я довольно новичок в разработке плагинов, и мне было трудно отлаживать.
Я использовал много эхо, и это небрежно и уродливо.
Я уверен, что есть лучший способ сделать это, может быть, IDE с отладчиком, в котором я могу запустить весь сайт, включая плагин?
Я не видел IDE, которая полностью запускает WordPress внутри IDE… хотя это было бы здорово. Я отлаживаю подключаемые модули, запуская WAMP локально и код в Dreamweaver. Если вы установите
WP_DEBUG
значение false, как рекомендует Джон, вы получите довольно хорошее представление о том, что происходит не так, если что-то происходит в ваших сценариях. Затем вы можете отредактировать в Dreamweaver, нажав Ctrl+S, а затем F5 в браузере, чтобы немедленно просмотреть изменения.@EAMann — обязательно ознакомьтесь с PhpEd (для Windows) и PhpStorm+XDEBUG (для Mac, Linux и Windows).
Я бы также проверил другую статью Начина: andrewnacin.com/2010/04/23/5-ways-to-debug-wordpress
С PHP 5.4+ вы, вероятно, будете завалены уведомлениями E_STRICT. Перетащите эту суть в папку плагинов и активируйте, чтобы удалить строгие уведомления, деактивируйте, чтобы вернуться к обычному сервису.
Хороший ход. Горячие клавиши в редакторах рулят!
Я предпочитаю вывод, заданный
print_r($var, true)
вместоvar_dump
.Вау, меня заминусовали за рекомендацию платного плагина, с которым я никак не связан? Это немного тяжело, не так ли?
Я не тот, кто голосует против, но я не удивлен. Вы используете слова, как будто пытаетесь продать плагин. Рекомендовать что-то — это хорошо, но навязывать рекламу, как «абсолютную Божью манну». Люди ненавидят рекламу. Просто смягчите формулировку, и рекомендация будет говорить сама за себя.
Как это настроить?
Просто зайдите на их справочный сайт: jetbrains.com/help/phpstorm/2016.2/configuring-xdebug.html.
Зайдите в wp-config.php и измените
define('WP_DEBUG', false);
наdefine('WP_DEBUG', true);
. Кроме того, установите подключаемый модуль «Уведомления об устаревших журналах» Эндрю Насина.Если вы получаете сообщения об ошибках, то x-debug — прекрасное расширение PHP, которое добавляет в PHP современные обратные трассировки.
Если вы пытаетесь выяснить, что происходит там, где нет ошибок, мой любимый подход — определить функцию, которая записывает свои выходные данные в файл. Итак, я делаю plog($variable), и это появляется в файле журнала, который я затем могу просмотреть. Это особенно полезно, когда вы пытаетесь выяснить, что произошло до вызова header(), или в других ситуациях, когда вы не можете вывести данные в STDOUT.
Используйте xdebug + IDE NetBeans. При полной настройке — что легко сделать — вы можете установить точки останова в своем плагине и отслеживать переменные в точках останова. Я думаю, что это лучший способ отлаживать плагины или любые php-приложения в этом отношении.
Поработав с несколькими IDE, я остановился на старом добром Notepad++ с очень индивидуальной цветовой схемой подсветки синтаксиса.
У меня есть макрос, настроенный таким образом, что когда я нажимаю Shift-Ctrl-X, следующий код выводится там, где находится мой курсор:
Это просто, но обычно я могу выследить 90% своих ошибок с помощью этого макроса и включенного WP_DEBUG.
Я отлаживаю по старинке,
error_log()
инг иvar_dump
инг. Я считаю, что это самый эффективный способ для меня, у меня есть несколько функций-оболочек для обработки разных типов данных, такerror_log
как массивы и объекты могут быть проблемой. Кроме того, использованиеprint_r()
in может быть сложным для чтения, если оно не находится в файле<pre>
. У меня естьtj_log()
для регистрации ошибок иtj()
для отображения вывода (который в основном показывает любой тип данных в презентабельном виде:Тогда я просто делаю:
tj( $current_user );
или что-то еще.Я написал небольшой класс для создания файла журнала, он очень полезен при отладке вызовов ajax.
http://github.com/hunk/Magic-Fields/blob/master/tools/debug.php
Вам нужно сделать что-то вроде:
Debug::log(«Это отладочное сообщение»);
Когда эта строка будет выполнена, сообщение будет добавлено в файл журнала, и после этого вы можете использовать команду tail (если вы используете операционную систему в стиле Unix)
хвост -f файл_журнала.log
Если вы можете передать этой функции массив или объект.
обратите внимание, что вам нужно изменить строку 20 на путь, по которому вы хотите сохранить файл журнала.
Я использую Aptane IDE в Linux и UltraEdit в Windows, а в этой тоже есть PHP-парсер. Кроме того, я просматриваю все подсказки от xDebug с константой,
WP_DEBUG
определенной вwp-config.php
.См. также мой пост на эту тему и не стесняйтесь комментировать и оставлять отзывы о ваших инструментах разработки.
Я рекомендую проверить FirePHP. Вы можете отправлять отладочную информацию в Firefox Firebug через HTTP-заголовки, что обычно делает вывод отладки более чистым.
Не так уж и плохо: Eclipse Он близок к PhpStorm + бесплатный.
Есть две IDE, которые я могу порекомендовать, и я активно использовал обе: PhpED (только для Windows) и PhpStorm + XDEBUG (Mac, Windows и Linux). Сейчас я на Mac, поэтому могу использовать только последнюю.
Оба они РОК! Хорошая новость в том, что PhpStorm стоил 49 долларов до сентября 2010 года и всего 99 долларов после этого. Если бы я был на Windows и мне пришлось выбирать снова, не уверен, что бы я выбрал.
Откровенно говоря, я не могу не чувствовать, что любой разработчик плагинов, не использующий один из этих двух инструментов, серьезно ограничен, особенно если он относительно новичок в разработке плагинов WordPress.
Krumo — стилизованный класс отладки php
Еще одна действительно приятная вещь — класс php «krumo». Он реализован за ½ минуты и предлагает простой способ отладки всех видов переменных:
Кроме того, это помогает с отслеживанием, показывает загруженные классы или включенные файлы и все по запросу.
К тому же это БЕСПЛАТНО!
Скачать
Крумо @sourceforge
Я использую плагин LogPress за 13 долларов, который вы можете купить на ThemeForest, и это абсолютная удача. Вы можете отлаживать все, что касается их плагинов и сайта. Поддерживает ведение журнала консоли Firebug и многое другое. Я не могу жить без него, поэтому я использую этот плагин.
Этот плагин, вероятно, является лучшей суммой, которую я когда-либо тратил, и он сэкономил бесчисленное количество часов при разработке моего плагина для WordPress.
Я использую phpED и xdebug, но для меня (и, кажется, для кого-то еще) невозможно отладить плагины или файл темы! Отладчик останавливается только на точках останова, которые находятся в основных или исходных «основных» файлах! кто-нибудь может мне помочь?
Во- первых, я добавляю
define('WP_DEBUG', false);
файл wp-config.php (как сказали большинство людей) к моей локальной установке, которая является последней копией соответствующего производственного сайта (как файлов, так и данных). Это делает вещи быстрыми, безопасными, отдельными, но хорошо отражает, по крайней мере, одно место, где плагин действительно будет использоваться.Я также добавляю плагин Debug Bar вместе с некоторыми надстройками 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 и Saveing What для получения конкретной информации о сообщениях.
PHPStorm и Xdebug — это игра, которая меняет для меня правила разработки WordPress. Очень рекомендую сейчас. Особенно с их встроенными инструментами отладки.