Многие считают, что добиться успешного запуска отладки xdebug после его установки - тяжело и мучительно. Но на самом деле, сделать первый запуск можно менее чем за минуту, не делая настройку и даже не прикасаясь к конфигурационным файлам .ini (php.ini/xdebug.ini). Как это сделать? Об этом и пойдет речь в этой статье.
В чем же фокус?
Есть два вида отладки php - отладка Web-приложения, и отладка CLI-скрипта. При первом варианте отладка запускается через браузер, и это тот вариант, которым пользуется большинство людей, и которому посвящены почти все мануалы. В данном случае действительно нужно танцевать с бубнами делать настройку. При втором же варианте, php-скрипт запускается напрямую в IDE (она запустит его в консоли, но уже без вашего участия).
Так вот, нас интересует второй вариант, поскольку его ключевое отличие от первого состоит в том, что всякие там директивы (по типу xdebug.client_host
), не нужно прописывать в файле xdebug.ini и где-бы то ни было еще, они передаются в момент запуска динамически, а IDE заполняет их автоматически. Все что вам нужно после установки xdebug - это создать конфигурацию PHP Script в Phpstorm, подключить к ней интерпретатор, а к нему прописать подключение xdebug в поле Debugger Extension - его значение пойдет в директиву zend_extension
(как заполнять - смотреть тут, пункты 2 и 4), и не забыть нажать Reload phpinfo.
А дальше просто нажимаем кнопку запуска, и запускаем отладку без танцев с бубнами
Вариант без ручного создания конфигурации PHP Script
Нужно указать интерпретатор дефолтным для проекта (предполагается, что подключение xdebug там уже прописано):
И тогда можно просто запустить отладку текущего открытого файла:
Тогда конфигурация будет создана автоматически, и будет использовать интерпретатор по умолчанию.
Кстати, что интересно, в большинстве мануалов по настройке xdebug (например тут), подключение интерпретатора является обязательным пунктом, хотя по факту это лишнее действие - так как в итоге запускается web-отладка.
Данный вариант подходит как для локальных подключений, так и для удаленных (SSH), и для Docker тоже - интерфейс Phpstorm позволяет подключать интерпретатор из всех вышеперечисленных источников.
Вероятность успешного запуска с первой попытки высокая, но не 100%
Например, если на сервере закрыты порты отладки 9000/9003, то отладка не запустится. В таком случае нужно будет пробросить SSH- туннель:
ssh -R 9003:localhost:9003 username@host-ip
А также установить в настройках интерпретатора директиву xdebug.client_host
cо значением localhost
.
Также есть баг Phpstorm, что отладка не запускается, если Phpstorm установлен в Program Files, а не в папке пользователя (C:\Users\UserName\AppData\Local\Programs\PhpStorm). В таком случае SSH-туннель тоже должен помочь, ну или же переустановить Phpstorm в нужную папку.
А для запуска web-отладки все по-прежнему?
Ну во первых она вам может и вовсе не пригодиться, если вам нужно отлаживать не все web-приложение целиком, а отдельный скрипт. А во вторых, если нужна отладка все таки приложения, то настраивать конфигурацию конечно придется, но если вам до этого удалось успешно запустить отладку CLI-скрипта, то и с web-отладкой вам будет намного проще. Это как все тот же Hello World, но в мире дебага - как только получилось его запустить, то половина дела (а то и больше) уже сделана.
Расписывать настройку для Web-отладки не буду, так как об этом есть и так достаточно мануалов. Мне они к тому же обычно и не пригождаются, я просто помню о том, что:
-
На стороне сервера нужно заполнить хотя бы минимальную конфигурацию в xdebug.ini/php.ini, и после этого перезапустить веб-сервер.
Пример конфигурации
Вот пример минимальной конфигурации для удаленной отладки на linux, где не нужно пробрасывать SSH-туннель:
zend_extension=xdebug xdebug.mode=debug xdebug.discover_client_host=on
Туннель не нужен, поскольку благодаря директиве xdebug.discover_client_host, автоматически определяется ваш IP-адрес. Но использовать это нужно с осторожностью, потому что отладку тогда сможет запустить любой, кто откроет страницу приложения. Если сервер доступен извне, то безопасней будет все же использовать
xdebug.client_host=localhost
, и пробрасывать SSH-туннель. Но для первого запуска можно использоватьxdebug.discover_client_host
.Вместо
localhost
можно захардкодить ваш IP, тогда туннель будет не нужен, но отладку кроме вас никто не сможет запустить. А для Docker и вовсе обычно указываютxdebug.client_host=host.docker.internal
. Должна быть создана и запущена конфигурация PHP Remote Debug, с сервером, в котором будут указаны маппинги, и указанным ключом IDE key (обычно это
PHPSTORM
, но зависит от браузерного расширения Xdebug).В браузере должно быть расширение для работы с Xdebug с активированным жуком
Все остальное, о чем пишут в мануалах - подключение CLI-интерпретатора, подключение DBGP-proxy в Phpstorm - необязательно.
Или можно zero debug configuration, но он работает не всегда
В данном случае не нужно создавать конфигурацию PHP Remote Debug. Нужно только заполнить конфиг в ini, а дальше достаточно только включить прослушивание входящий соединений в Phpstorm.
Ну и активировать жука в браузере. И дальше можно в браузере запускать файл/страницу, в котором предварительно была поставлена точка останова.
И бонус
Возможно вы не знали, но в сеансе отладки можно не только смотреть значения переменных, но и выполнять выражения:
А также выполнять их в отдельном окне:
Это помимо консоли, где вы можете тоже выполнять код, но туда его нужно будет копировать вручную. Учтите, что выполнение кода и выражений может повлиять на ход выполнения программы (если например изменять значения переменных).
Комментарии (8)
Mausglov
03.11.2024 21:22discover_client_host очевидно, не сработает, если у Вас серый IP. Схема работы xDebug проста и очевидна, но бывает, что люди про неё не читали и предполагают какую-то магию. Поэтому коротко приведу её для варианта web отладки:
Вы инициируете в IDE сессию отладки
IDE начинает слушать входящие соединения на заданном порту ( по дефолту 9003)
IDE отправляет обычный HTTP запрос на целевой хост
на хосте при обработке PHP кода xDebug инициирует исходящее соединение на заданный порт.
Поэтому важно, чтобы либо хост в пунктах 2 и 4 совпадал, либо между хостами должно быть какое-то соединение ( например, обратный ssh туннель, как в статье ). Иначе получается так, что PHPStorm при проверке удалённой отладки ( есть там кнопочка) говорит, что всё хорошо, но отладка не работает.
Когда у Вас серый IP, а отладку Вы хотите провести на удалённом сервере, где PHP запущен в Docker контейнере, заставить всё это работать непросто.
InfluxOW
03.11.2024 21:22Ещё несколько лет назад много раз пытался настроить XDebug в PHPStorm для Laravel под Ubuntu, но никак не получалось, хотя следовал всем гайдам и пробовал бесконечное количество разных вариантов. Много раз брался за эту задачу и много раз бросал, потому что ничего не получалось. Спустя какое-то время сел разбираться в очередной раз, тогда-то и почти случайно и выяснил, что проблема была в файрволле, - надо было открыть 9000 и/или 9003 порты, после чего всё заработало. И в этом гайде про такую проблему тоже ничего не сказано, так что имейте в виду.
alexandr_domanskiy
03.11.2024 21:22Всегда использую докер. Поднимаю отдельными контейнерами nginx, php, bd, composer, artisan. Xdebug приходится настраивать по используемую версию php. Где-то только дебагер, а где-то нужно и профайлер добавить. Тут нет ничего сложного. Один раз настроить и пользоваться.
gun_dose
03.11.2024 21:22Расширение для браузера тоже необязательно. Ещё 8 лет назад у меня закралась мысль, что оно ничего не делает, и я его снёс, и всё работает. Надо поставить start_with_request=yes, а в шторме нажать кнопку, которая слушает входящие соединения. Будет ловить из всех браузеров, из постмана и т.д.
TimsTims
03.11.2024 21:22Расширение (если мы говорим про то, которое включает нужную Куку) полезно тем, что оно включает дебаг только при необходимости.
Надо поставить start_with_request=yes
Эта команда включает дебаг при любом запросе. Это стоит ресурсов сервера. Кроме того, злоумышленник можно зайти и попросить сервер отправить ему весь дебаг (в том числе данные подключения к базе данных итд). Поэтому используйте дебаг с осторожностью.
TimsTims
03.11.2024 21:22Расширение (если мы говорим про то, которое включает нужную Куку) полезно тем, что оно включает дебаг только при необходимости.
Надо поставить start_with_request=yes
Эта команда включает дебаг при любом запросе. Это стоит ресурсов сервера. Кроме того, злоумышленник можно зайти и попросить сервер отправить ему весь дебаг (в том числе данные подключения к базе данных итд). Поэтому используйте дебаг с осторожностью.
den_rad
Давно пользуюсь docker образами c xdebug, настройка занимает очень мало времени.