Comments 17
Судя по всему вот репозиторий. Насколько он официален — не знаю, но различий в коде между тем, что по вашей ссылке и в этом репозитории — немного.
Отладка в режиме php-fpm несколькими разработчиками выходит за рамки данной статьи, но описана, например, здесь
ссылку забыли подставить
О! Рад что проект не заброшен. А вообще удивительно что при такой популярности php реализаций прокси так мало.
Хорошее дело, надо развивать.
Хорошее дело, надо развивать.
Согласен. Сам был удивлён, когда не нашел ни одной прокси на php.
При популяризации Docker многопользовательская разработка на единственном тестовом (dev) окружении стала вымирать. Да и, вообще, компаний, которые могли бы похвастаться невоспроизводимым окружением всегда были единицы.
Для чего вы используете (планируете или хотели бы использовать) xdebug proxy?
Окружение для разработки допустим у каждого разраба своё (не полностью идентичное продакшену, в частности по БД), но есть например стэйдж-сервер, на который собирается проект от разных разрабов, при этом на стейдже окружение максимально приближенное к проду включая данные (свежие дампы БД к примеру) — и все разрабы, пуллы которых тестируются — могут спокойно проверять каждый свой участок.
Другой способ сделать soft mocks отлаживаемыми я подглядел у похожего на soft mocks проекта, но детали немного отличаются. Даже прислал pull request довольно давно: github.com/badoo/soft-mocks/pull/35/files.
Суть заключается в том, что вместо того, чтобы SoftMocks::rewrite() переписывал путь до файла и возвращал уже переписанное содержимое, можно возвращать путь-враппер вида «soft://».
Магия заключается в том, чтобы зарегистрировать обработчик стрима «soft://» (класс SoftMocksStream в этом pull request) и возвращать оригинальное имя файла:
Также становятся ненужными встроенные моки для debug_backtrace и в некоторых других местах, так как backtrace становится «нормальным» (без враппера soft://, что немаловажно) и для xdebug тоже этого достаточно, чтобы он «поверил», что имя файла оригинальное.
Суть заключается в том, что вместо того, чтобы SoftMocks::rewrite() переписывал путь до файла и возвращал уже переписанное содержимое, можно возвращать путь-враппер вида «soft://».
Магия заключается в том, чтобы зарегистрировать обработчик стрима «soft://» (класс SoftMocksStream в этом pull request) и возвращать оригинальное имя файла:
<?php
class SoftMocks {
...
- private static function doRewrite($file)
+ public static function doRewrite($file, &$opened_path = '')
...
}
class SoftMocksStream {
...
public function stream_open($path, $mode, $options, &$opened_path) {
...
$rewritten = SoftMocks::doRewrite($path, $opened_path);
...
$this->fp = fopen($rewritten, $mode);
...
}
}
Также становятся ненужными встроенные моки для debug_backtrace и в некоторых других местах, так как backtrace становится «нормальным» (без враппера soft://, что немаловажно) и для xdebug тоже этого достаточно, чтобы он «поверил», что имя файла оригинальное.
UFO just landed and posted this here
Туннель поможет, если на один php-fpm будет один разработчик. В случае же когда на один php-fpm несколько разработчиков, Xdebug не будет знать, в какой туннель ему идти. Xdebug proxy позволяет определить нужный туннель по `idekey`.
В xdebug есть встроенный multiuser-механизм (remote_connect_back), чем он не подошел?
Да есть, но в случае закрытой сети он работать не будет. Например, если разработчик сидит за NAT-ом.
Есть версия этой статьи на английском?
В планах есть перевести эту статью на английский. Я скину сюда ссылку, когда переведём.
Как и обещал, вот ссылка на перевод https://badootech.badoo.com/php-xdebug-proxy-when-xdebugs-standard-capabilities-are-insufficient-49fe86943f12
Sign up to leave a comment.
PHP Xdebug proxy: когда стандартных возможностей Xdebug не хватает