Многие считают, что добиться успешного запуска отладки 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-отладки не буду, так как об этом есть и так достаточно мануалов. Мне они к тому же обычно и не пригождаются, я просто помню о том, что:

  1. На стороне сервера нужно заполнить хотя бы минимальную конфигурацию в 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.

  2. Должна быть создана и запущена конфигурация PHP Remote Debug, с сервером, в котором будут указаны маппинги, и указанным ключом IDE key (обычно это PHPSTORM, но зависит от браузерного расширения Xdebug).

  3. В браузере должно быть расширение для работы с Xdebug с активированным жуком

Все остальное, о чем пишут в мануалах - подключение CLI-интерпретатора, подключение DBGP-proxy в Phpstorm - необязательно.

Или можно zero debug configuration, но он работает не всегда

В данном случае не нужно создавать конфигурацию PHP Remote Debug. Нужно только заполнить конфиг в ini, а дальше достаточно только включить прослушивание входящий соединений в Phpstorm.

Ну и активировать жука в браузере. И дальше можно в браузере запускать файл/страницу, в котором предварительно была поставлена точка останова.

И бонус

Возможно вы не знали, но в сеансе отладки можно не только смотреть значения переменных, но и выполнять выражения:

Quick Evaluate Expression, вызывается через Alt+Shift+MouseClick либо Ctrl+Alt+F8 (в первом варианте будет автоподчеркивание)
Quick Evaluate Expression, вызывается через Alt+Shift+MouseClick либо Ctrl+Alt+F8 (в первом варианте будет автоподчеркивание)

А также выполнять их в отдельном окне:

Evaluate Expression, вызывается через Alt+F8, но для автоподчеркивания нужно назначить Mouse Shortcut, например Alt+Shift+RightMouseClick
Evaluate Expression, вызывается через Alt+F8, но для автоподчеркивания нужно назначить Mouse Shortcut, например Alt+Shift+RightMouseClick

Это помимо консоли, где вы можете тоже выполнять код, но туда его нужно будет копировать вручную. Учтите, что выполнение кода и выражений может повлиять на ход выполнения программы (если например изменять значения переменных).

Комментарии (8)


  1. den_rad
    03.11.2024 21:22

    Давно пользуюсь docker образами c xdebug, настройка занимает очень мало времени.


  1. Mausglov
    03.11.2024 21:22

    discover_client_host очевидно, не сработает, если у Вас серый IP. Схема работы xDebug проста и очевидна, но бывает, что люди про неё не читали и предполагают какую-то магию. Поэтому коротко приведу её для варианта web отладки:

    1. Вы инициируете в IDE сессию отладки

    2. IDE начинает слушать входящие соединения на заданном порту ( по дефолту 9003)

    3. IDE отправляет обычный HTTP запрос на целевой хост

    4. на хосте при обработке PHP кода xDebug инициирует исходящее соединение на заданный порт.

    Поэтому важно, чтобы либо хост в пунктах 2 и 4 совпадал, либо между хостами должно быть какое-то соединение ( например, обратный ssh туннель, как в статье ). Иначе получается так, что PHPStorm при проверке удалённой отладки ( есть там кнопочка) говорит, что всё хорошо, но отладка не работает.

    Когда у Вас серый IP, а отладку Вы хотите провести на удалённом сервере, где PHP запущен в Docker контейнере, заставить всё это работать непросто.


  1. InfluxOW
    03.11.2024 21:22

    Ещё несколько лет назад много раз пытался настроить XDebug в PHPStorm для Laravel под Ubuntu, но никак не получалось, хотя следовал всем гайдам и пробовал бесконечное количество разных вариантов. Много раз брался за эту задачу и много раз бросал, потому что ничего не получалось. Спустя какое-то время сел разбираться в очередной раз, тогда-то и почти случайно и выяснил, что проблема была в файрволле, - надо было открыть 9000 и/или 9003 порты, после чего всё заработало. И в этом гайде про такую проблему тоже ничего не сказано, так что имейте в виду.


    1. a43mx Автор
      03.11.2024 21:22

      Сказано, просто это в спойлере


  1. alexandr_domanskiy
    03.11.2024 21:22

    Всегда использую докер. Поднимаю отдельными контейнерами nginx, php, bd, composer, artisan. Xdebug приходится настраивать по используемую версию php. Где-то только дебагер, а где-то нужно и профайлер добавить. Тут нет ничего сложного. Один раз настроить и пользоваться.


  1. gun_dose
    03.11.2024 21:22

    Расширение для браузера тоже необязательно. Ещё 8 лет назад у меня закралась мысль, что оно ничего не делает, и я его снёс, и всё работает. Надо поставить start_with_request=yes, а в шторме нажать кнопку, которая слушает входящие соединения. Будет ловить из всех браузеров, из постмана и т.д.


    1. TimsTims
      03.11.2024 21:22

      Расширение (если мы говорим про то, которое включает нужную Куку) полезно тем, что оно включает дебаг только при необходимости.

      Надо поставить start_with_request=yes

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


    1. TimsTims
      03.11.2024 21:22

      Расширение (если мы говорим про то, которое включает нужную Куку) полезно тем, что оно включает дебаг только при необходимости.

      Надо поставить start_with_request=yes

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