как отлаживать php код
Отладка php в Visual Studio Code (Xdebug, Windows)
В некоторых случаях может возникнуть необходимость отладки приложений на php. Visual Studio code предоставляет такую возможность при условии установки дополнительного расширения PHP Debug (marketplace, github).
Установка PHP Debug
Установка и настройка Xdebug
PHP Debug использует для отладки Xdebug. Для настройки Xdebug пройдите по ссылке. Предполагается, что на локальной машине уже установлен и настроен сервер apache. Здесь и далее действия указаны для Windows. Можно создать файл, например, test.php содержащий:
Открыть его в браузере и скопировать содержимое страницы в диалоговое окно. Другой способ:
Кроме этого, добавьте нижеследующие строки. Итоговое добавление будет примерно таким:
Как вы уже, возможно догадались, в данном примере на локальной машине установлен XAMPP.
Примечание: С версией Xdebug 2.5 и выше Visual Studio code не работает. Поэтому выбирайте соответствующий вашей версии php файл *.dll.
Настройка Visual Studio code
Вызовите панель отладки (1) и нажмите на иконку с маленькой шестеренкой (2).
Настройка PHP Debug на этом окончена.
Отладка php в Visual Studio code
Откройте в браузере ваше приложение\сайт. Откройте папку с приложением в Visual Studio code. Установите в нужных файлах и строках точки остановки. Откройте панель отладки и выберите для запуска отладки команду Listen for Xdebug (1). Нажмите кнопку запуска (2).
Обновите страницу в браузере и наслаждайтесь.
Простой способ отладки программ на PHP
Я пользуюсь этим методом отладки программ на PHP уже лет, наверное, 10. И ещё ни разу он меня не подводил. Почему я решил поделиться этим способом с вами? Наверное потому, что больно смотреть на новичков, которые берут откуда-то код, или пишут приличную портянку сами, он (естественно) не работает и они начинают хаотично менять всё подряд, пытаясь каким-то способом “нащупать” то место, где таится ошибка. Но это на самом деле сложный путь, который не всегда приводит к результату. Итак, вот что я предлагаю.
Главное при отладке программ и поиске “багов” – это терпение и последовательность в действиях. Если вы не будете соблюдать пошаговый алгоритм, то ничего не получится, в итоге вы запутаетесь и ни к чему не придёте.
Сам пошаговый алгоритм сводится к последовательной расстановке меток в программе, обновлению страницы и наблюдению выводимой информации в браузере. Лучше всего начать всего с одной метки.
Каждая метка выглядит примерно так
Интерпретатор кода PHP, дойдя до такой метки сделает следующее: выведя “1” в браузер, он немедленно прекратит выполнение кода программы. Таким образом, вы узнаете, что выполнение кода программы дошло до этого места, так как на экране будет выведена единичка и это будет последнее, что отобразится в браузере. Нет ничего проще, чтобы узнать – доходит ли до этой точки интерпретатор.
Вы можете не ставить exit(), если абсолютно уверены в том, что код не обновляет страницу после вывода (нет рефреша).
Дальнейшие действия могут быть следующими:
Общее правило: продвигайтесь по коду очень медленно, стараясь не пропустить того момента, где таится баг. Старайтесь чаще использовать метод половинного деления.
Вывод значений переменных
Но что толку от того, что интерпретатор дошёл или не дошёл до какого-то места? Малоинформативно. Давайте добавим больше жизни!
Часто необходимо вывести значения конкретных переменных в конкретной точке кода. И тут нам пригодятся две мощнейшие функции – print_r() и var_dump(). Вот как их можно использовать.
Для того, чтобы увидеть содержимое переменной, используем print_r($var); или print_r($obj->var) если нужно посмотреть содержимое свойства конкретного объекта. Для того, чтобы увидеть значение true или false, используем var_dump(). Тут необходимо пояснить кое-что. Функция print_r() специально была придумана для того, чтобы красиво выводить значения разных типов. Причём она выводит и целые, и строки, и массивы и даже объекты. А вот true и false она не выводит, то есть вывод всегда будет равен пустой строке. Тут на помощь приходит var_dump(), который выводит точное значение и тип этого значения.
Использовать var_dump() везде я не рекомендую. Вывод, им генерируемый, выглядит намного запутаннее, чем вывод от print_r().
Итого, вот как будет выглядеть наша информативная метка:
Обычно я дублирую номер метки в обрамлении других символов, чтобы видеть, где закончился вывод тестируемых переменных. Это часто бывает полезно.
Можно ещё перед каждым print_r() выводить echo “var=”; чтобы понимать где и чьё значение отображается.
Замер времени выполнения части кода
Очень часто при профайлинге (а ещё чаще при поиске “тормозов” в коде) бывает необходимо замерить реальное время выполнения конкретного куска кода.
В PHP есть замечательная функция microtime(), которая возвращает текущее время в микросекундах. Если ей указать параметр true, то она будет возвращать его в виде числа с плавающей точкой, что нам и нужно.
Идея способа замера времени выполнения куска кода сводится к тому, чтобы запомнить текущее время перед началом этого куска и сравнить его с текущим временем в конце куска. То есть вот так:
При этом после метки мы увидим время, потраченное на выполнение кода в секундах. Часто вы будете видеть что-то типа такого: 1.233433E-05, это инженерная форма записи очень малых и очень больших чисел. Можно привести её в нормальный вид, добавив функцию sprintf():
Немного больше кода, но зато вы будете видеть нормальные числа вроде 0.000012, т.е. 12 микросекунд.
Вот и всё на сегодня, завтра я напишу специальную статью, в которой расскажу об ещё одном способе отладки с использованием выгрузки лога в файл (бывает полезно, если не хочется нарушать нормальную работу сайта, то есть вывод разных меток на страницу недопустим).
Спасибо за внимание, не забудьте подписаться, чтобы не пропустить очередную статью!
Замолвим слово об отладке и профилировании [PHP]
Все идет от лени. Вы получили чужой очень большой проект в котором нужно сделать небольшие правки, или же написали скрипт и сразу не очевидно, что в нем еще требует оптимизации. Как быть? Читать и анализировать код, выводить каждый шаг на экран или в файл (var_dump() и т.д.) не всегда эффективно, ведь можно воспользоваться средствами отладки, которых на сегодняшний день очень много. Кратко перечислю часто встречающиеся…
Xdebug Debugger and Profiler Tool — расширение PHP. Требует установки на сервер и настройки. Может отображать: стек вызовов функций, распределение памяти. Возможности: профайлинг, анализ покрытия кода, защита от бесконечной рекурсии, интерактивная отладка скриптов. ПО для визуализации логов xdebug: Webgrind – веб-интерфейс для профайлинга Xdebug, написанный на PHP, MacGDBp – Mac OS X клиент, который позволяет отлаживать PHP приложения при помощи Xdebug. Linux GUI kcachegrind. Бесплатный. Интегрируется с многими IDE. См Profiling PHP Applications With xdebug. При включении опции в php.ini:
будет форматировать вывод var_dump() и сообщения об ошибках.
Xhprof — расширение PHP от facebook. Требует установки на сервер и настройки. Позволяет собирать время выполнения каждой функции, использование памяти, время ожидания, количество вызовов и многое другое. Это расширение доступно из репозитория PECL. Почитать документацию можно тут [тыц]. Так же Профилирование и отладка php-приложений с помощью xhprof & FirePHP. Из преимуществ сильно не грузит систему, можно ставить на бой. Бесплатный.
DBG (PHP Debugger and Profiler) — расширение PHP. Требует установки на сервер и настройки. Позволяет работать на тестовом или/и рабочем сервере и отлаживать скрипты локально или удаленно, из IDE или консоли. Платная/бесплатная версии.
ZendDebug — расширение PHP, входит в состав Zend Studio (платная IDE). Требует установки на сервер и настройки. Позволяет практически все тоже, что и xdebug, GUI в IDE Zend Studio или Zend Server. Платный. Чуть ниже рассмотрим его более подробно.
Memtrack — расширение PHP. Позволяет искать утечки памяти. Удобно проверять скрипты запускаемые по крону или в качестве демона. Бесплатный. См. [тыц]
APD Advanced PHP debugger — расширение PHP. Слабый конкурент xdebug, но имеет в себе возможности memtrack. Плохо интегрируется с IDE, однако имеет консольный интерфейс (см. [тыц]). Бесплатный.
FirePHP — класс, написан на php + расширение для FireFox. Дает возможность посылать отладочные сообщения в консоль Firebug с помощью вызова php методов. Вся информация посылается через заголовки X-FirePHP-Data, тем самым не пересекаясь с основным контентом страниц. Бесплатный. См. Отладка PHP средствами Firebug
php-console — написан на php + расширение для Google Chrome. Аналог FirePHP, только для Google Chrome, но несколько с другим функционалом. Бесплатный. См. php-console
PHP_Debug класс, написан на php. Помогает в отладке PHP кода, показывает путь выполнения скрипта, отображает все переменные, время выполнения, включенные файлы, выполненные запросы, watch переменные… Эта информация собирается во время выполнения скрипта, и отображается по его завершению и потом может быть использована в любой момент. Бесплатный.
Отладчики в современных CMS/CMF/Framework. Их не рассматриваем, т.к. зачастую они имеют специфику и разработаны под конкретную оболочку, что делает не возможным использование их извне (IDE) или применять без значительных изменений в своих разработках.
Для сбора и анализа узких мест в ваших приложениях иногда может пригодится методика централизованного хранении syslog, см [тыц].
Вернемся к ZendDebug. Так как я в основном пользуюсь Zend Studio, то мне наиболее удобно с ним работать. Он позволяет сразу понять ход выполнения скрипта, поддерживает навигацию по коду из IDE. Не нужны никакие сторонние инструменты, кроме IDE. Это действительно удобно, так сказать настроил один раз и пользуешься.
Отладка и профилирование скриптов в Zend Studio возможна как минимум двумя способами при помощи xdebug или ZendDebug. Только вот профилирование сайта с xdebug у меня не заработало, пишет что нельзя так — только отладка.
Про локальную отладку кода писали еще во времена Zend Studio 5.5 [тыц]. С тех времен мало что изменилось. Но я столкнулся с проблемой, когда web сервер и отлаживаемый код находится на удаленном сервере. Часто такие песочницы закрыты извне, а отрыты только нужные для работы порты. Но если к такой песочнице есть доступ по SSH, то настроить ZendDebug все таки можно, не мешая фаерволу выполнять свою функцию.
Забегая вперед отмечу, что для этого нужно будет создать SSH туннель. Немного о том, зачем SSH туннель нужен в этом случае.
По умолчанию Zend Studio инициирует сеанс удаленной отладки, отправив HTTP запрос на отладочный сервер. Этот запрос содержит параметры обратного адреса (IP-адрес и номер порта), который ZendDebug (установленный на сервере) использует при запуске нового подключения к Zend Studio, чтобы ретранслировать информацию об отладке. Кстати, инициализировать сам сеанс отладки можно как из IDE, так и из браузера установив компонент, поставляемый вместе с Zend Studio, будет довольно удобно.
Обычная отладочная сессия будет иметь место, например, в случае, когда код, WEB сервер и IDE находятся на локальном компьютере.
Но зачастую WEB сервер разделен с IDE брандмауэрами, маршрутизаторами, прокси-серверами т.д. Тут-то и пригодится SSH туннель.
В случае с туннелем процесс установления сеанса отладки состоит из двух основных этапов:
— создания SSH туннеля;
— настройки Zend Debugger, для передачи своего трафика через SSH туннель.
Схема отладочной сессии через SSH туннель примет вид:
Обычная отладочная сессия через SSH туннель
Zend Studio, по умолчанию, открывает порт 10137. Его и будем использовать в примерах далее. Можно назначить и другой порт, если это необходимо.
Создание SSH туннеля в Linux или Mac OS X можно в командной строке:
ssh :127.0.0.1: @пример:
Для создания SSH туннеля в Microsoft Windows, можно использовать PuTTY. После создания рабочего SSH соединения, необходимо дополнительно настроить туннель.
Со стороны IDE проверьте, что слушаются порт 10137 и локальный IP адрес 127.0.0.1
Практика тенулирования трафика вам может пригодится и для других целей. Например локальными утилитами делать SQL-дампы СУБД, когда удаленная база разрешает соединение только с 127.0.0.1 и т.д.
Думаю из списка выше каждый сможет найти себе удобный инструмент на каждый день. И что бы разработка приносила еще больше удовольствия, а на вопрос — «Что случилось? Почему лежим?», был всегда оперативный ответ.
Приятной отладки и скриптов без ошибок, спасибо за внимание.
Отладка — PHP: Основы
Типы ошибок
Наиболее простые и понятные ошибки — синтаксические. Они связаны исключительно с тем, что код записан неверно, например, забыта точка с запятой в конце инструкции. В выводе таких ошибок всегда присутствуют фразы parse error и syntax error. Для их исправления нужно открыть то место в коде, на которое указывает ошибка, и внимательно на него посмотреть.
Еще одна большая группа ошибок называется ошибками программирования. К ним, например, относятся:
Эти ошибки исправить труднее, чем синтаксические. Обычно они возникают в результате неправильной логики в другом, более раннем вызове.
Последний тип ошибок — логические ошибки. Исправить такие ошибки бывает крайне сложно, так как программа продолжает работать, но выдает неверный результат. Причем обычно программа выдает неверный результат не всегда, а только лишь для некоторых входных данных. В подавляющем большинстве случаев проблема кроется в неверной логике, например, перепутана операция, и вместо сложения выполняется вычитание.
Отладка
Существует множество способов отладить программу, но какой бы способ вы ни выбрали, общая идея отладки сводится к анализу того, как меняются значения переменных в процессе работы кода.
В этом коде допущена ошибка. Вы ее видите? Если очень постараться, ее можно заметить, но на это никогда не надо надеяться. Новички часто думают, что они невнимательны и очень расстраиваются, когда допускают такие ошибки. Хочу вас успокоить: опытные разработчики допускают такие ошибки не реже новичков. Важно не то, что вы их допускаете, а то, что вы способны отладить этот код (и сделать это быстро). Этим отличаются опытные разработчики от начинающих. Никогда не пытайтесь найти ошибку с помощью медитации над кодом, сверля его взглядом. Если быстрая проверка не дала ответа, то приступайте к отладке.
На Хекслете, в обсуждении уроков, нам пишут: «этот код не работает», и показывают свой код. Вероятно, начинающие разработчики думают, что опытные могут понять, в чем ошибка и найти ее, просто посмотрев на код, но это совсем не так. Глядя на такой код, невозможно понять, а что, собственно, пошло не так, и я уже не говорю про нахождение самой ошибки. Нам также нужно увидеть сообщение об ошибке и начать отладку.
Один из способов отслеживать значения переменных во время выполнения кода связан с использованием отладчиков. Отладчики интегрируются с популярными редакторами и позволяют визуально выполнить код по шагам, отслеживая любые изменения. Подробнее о том, как их использовать можно прочитать во множестве статей (гуглить по запросу: xdebug php ).
В среде Хекслета отладчика нет, поэтому здесь используется другой подход (но выполняющий ту же задачу) — отладочная печать. Суть такая же, как и в визуальном отладчике, но для вывода значения переменных используется обычная печать на экран:
Эта функция добавляет в вывод перевод строки, но особенно удобно использовать ее с массивами, которые мы скоро изучим.
Дополнительные материалы
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты.
Настройка отладки php-кода при помощи Xdebug
Классические методы отладки на PHP — использование функций error_log, print_r и var_dump. Их проблема в том, что они не помогают отслеживать сам процесс работы кода. Однако с этой задачей справляется Xdebug — один из самых популярных инструментов среди PHP-разработчиков, которые хотят работать, а не страдать.
В этой статье будет рассмотрена отладка PHP с помощью связки Xdebug и VSCode. Если вы пользуетесь PHPStorm, то проблем тоже не будет — настройка выполняется даже проще и быстрее.
Возможности Xdebug
Xdebug — это расширение для PHP, которое позволяет использовать удаленный отладчик в IDE через брейк-пойнты. С его помощью вы можете отслеживать значения переменных. Как итог — ошибки в коде обнаруживаются быстрее, чем при использовании error_log, print_r и var_dump.
Еще одна полезная функция — трассировка стека. Она выводит подробный путь, который привел приложение к ошибке. Он содержит параметры, переданные в функцию. Xdebug также можно использовать как профайлер для поиска узких мест кода. Если добавить внешние инструменты, то получится визуализировать графики производительности. Например, можно использовать WebGrind — набор PHP-скриптов для удобного вывода статистики прямо в браузере.
Кроме того, с помощью Xdebug вы можете проследить, какая часть кода выполняется в процессе запроса. Это дает информацию о том, как хорошо код покрыт тестами.
Подключение Xdebug
Для работы Xdebug PHP должен быть в режиме CGI. Посмотрим на примере хостинга Timeweb, как его включить.
Подключаемся к серверу через SSH. Можно использовать консоль в панели управления Timeweb.
Переходим в папку cd-bin сайта:
Создаем символическую ссылку командой:
Остаемся в директории cgi-bin и копируем файл php.ini:
Теперь мы можем управлять параметрами PHP директивами в файле php.ini. Он находится в папке cgi-bin. Открываем его и вставляем в конце следующие строки:
Если указанный порт занят, укажите другой. Можно использовать стандартный для Xdebug — 9000. В качестве idekey я указал VSCODE. Если будете настраивать конфигурацию для PHPStorm, впишите его.
Чтобы проверить, работает ли Xdebug, создадим в корне сайта файл Myfile.php со следующим содержимым:
Открываем файл в браузере и проверяем, что все параметры указаны верно.
Организация удаленного подключения
Чтобы выполнять PHP Debug на локальной машине, нужно настроить связь IDE и сервера через SSH-туннель.
На Linux все выполняется парой команд.
Приватный ключ сохраняется на локальной машине, а публичный добавляется на сервер. Подробнее об этом, а также о настройке SSH на Windows, вы можете узнать из этой статьи.
На Linux туннель создается командой:
На Windows туннель настраивается через утилиту PuTTY.
Сессия сохранится под тем именем, которое мы указали в разделе Session. В дальнейшем нужно будет просто запускать ее заново.
Настройка VSCode
Чтобы работать с Xdebug в VSCode, установим два расширения: Sync-Rsync и PHP Debug. Первое нужно для работы с удаленным сервером, второе — для отладки скриптов.
После установки расширений создаем на локальной машине пустую папку и открываем ее через VSCode: «Файл» — «Открыть папку».
Путь /home/user/.ssh/id_rsa — это место, где лежит файл с закрытой частью SSH-ключа.
После сохранения файла settings.json нажимаем в VSCode F1, выполняем команду Sync Remote to Local. В локальную папку, указанную в настройках, скопируются все файлы с сервера.
На этом настройка IDE завершена. Можно приступать к тестированию кода.
Debug кода
Мы настроили среду, теперь разберемся, как пользоваться Xdebug.
Переходим в режим «Отладка» и проверяем, что выделен пункт Listen for XDebug. Нажимаем на зеленый треугольник или на клавишу F5.
После перезагрузки сайта в браузере возвращаемся в VSCode. В отладчике должны отобразиться глобальные переменные и их значения на момент обработки кода в брейк-пойнте. Вы можете перемещаться по коду, отслеживая изменение переменных на каждом шаге.
Профилирование с визуализацией результатов
Чтобы использовать Xdebug profiler на полную мощность, установим WebGrind. Это набор скриптов, который выводит статистику в браузере. С его помощью можно посмотреть список вызванных функций, количество вызовов, общее затраченное время на вызов и выполнение.
Затем нужно открыть файл config.php, который находится в распакованной папке webgrind-master. В нем отредактируем две строки:
После такой настройки можно выполнять на Xdebug профилирование. Открываем наш тестовый скрипт в браузере. Затем переходим по ссылке www.domain/webgrind-master. В выпадающем списке выбираем только что запущенный скрипт и нажимаем на кнопку Update.
Функции можно скрывать или раскрывать, чтобы посмотреть развернутую статистику. Инструмент также умеет отображать графы вызова функций — для этого используется режим Show Call Graph.
Вывод: когда использовать Xdebug?
Xdebug существенно упрощает отладку PHP-кода. Конечно, если ваш текущий инструментарий удовлетворяет все потребности в поиске багов, то устанавливать дополнительное расширение смысла нет. Но, как показывает практика, без Xdebug сложно провести правильное модульное тестирование или отладку через удаленные брейк-пойнты с возможностью пошаговой проверки кода.