PHPDump — Отладка в консоли Google Chrome и взаимодействие с CMS MODX

[MetaDone]

почему не приделали все это в виде обычного расширения/плагина/модуля или как там это называется в modx? В проекте на чем-то современном использовать это нет смысла т.к. уже существуют
http://phpdebugbar.com/
https://github.com/symfony/var-dumper
По самому коду — очень неряшливо написано, постоянные смешивания конструкций

	namespace Alpa\PhpDump;
	// the file for the autoloader will load when accessing the class.
	include_once __DIR__.'/../include_file_in_index.php';

и кучи закомментированных кусков кода
а также куски с дебаг-информацией
Ну и завязка на апач тоже не в плюс

[Agel_Nash]

Tracy легко внедряется и кастомизируется под любой проект

[MetaDone]

тоже хороший вариант. автору проще было бы интегрировать что-то из этого в modx чем писать с нуля то что он написал

[AlexeyP0708]

Проект является не только для MODX. Я написал его для себя. Просто поделился. Будет неоднократный рефакторинг и code review как руки дойдут. Но пока что работает, не хочу трогать и прокачивать.

[AlexeyP0708]

Почитал доку Tracy. Там при анализе объектов и массивов, есть ограничение по глубине вложений. Я в свое время встретился с таким же ограничением в PhpConsole и отсутствием детализированных данных. Это меня и побудило написать собственную реализацию по анализу массивов и объектов. В моем случае можно анализировать толстые объекты и массивы с неограниченной вложенностью. Конечно может возникнуть ошибка memory size, но она возникнет при очень жирных объектах. Пока это единственное ограничение. По степени необходимости, по этой части будет рефакторинг.
С объектом $modx со всеми его вложениями справляется в легкую. Также петли, не повлияют на анализ. Они вычисляются и исключаются.
А рекурсивная детализация объекта, не однократно спасала. Можно посмотреть как детализирует состояние объекта. через вызов \deb::dump($obj); Возможно есть другие компоненты которые я не до оценил. Но на меня нашло вдохновение написать что то собственное.

[Agel_Nash]

— Tracy это панель сводной информации куда удобно выводить вкладки (какие события были запущены и с какими параметрами) / какие чанки / сниппеты отработаны / под каким юзером работаете и т.п.
— Если говорить конкретно за дамп, то раз нет доступа к xDebug можно воспользоваться var-dumper как уже сказали выше. В Tracy он действительно немного убогий

По большому счету вы просто попытались совместить 2 инструмента в 1. Чтож, это ваше право…

[AlexeyP0708]

Причин несколько.
Реализация по большому счету не должна интегрироваться в фреймворки или CMS, а выполняться параллельно. Один раз установил на dev машине, потом где необходим анализ, в том проекте и подключаешь. Изначально пользовался с помощью плагина. Но почему отказался от такой реализации*? А до инициализации события MODXInit сколько строчек кода пропустим*? Может необходимо отладить код в самом MODX? К примеру, в один момент необходимо было провести анализ Index.php, чтобы внести свою корректировку для мультисайтовости. А если код падает до инициализации компонента, то вычислить проблему вообще не возможно. Если PHPDump будет запускать ранее до запуска основного сценария, то проблемы можно отслеживать.

[Agel_Nash]

Для запуска PhpDump на CMS MODX Есть несколько решений.

Вариант с плагином на событиях OnInitCulture или OnMODXInit был бы более предпочтителен

[SerafimArts]

По-моему, clockwork на порядок удобнее и полезнее будет. Туда не только дампы можно впихнуть, но и кучу другой сопутствующей информации. А т.к. это ещё и расширение для браузера, то можно и в API использовать, где не должно быть другой информации, вроде скриптов.

[NorthDakota]

Смотря на ваши куски кода, кровь из глаз идёт…

[AlexeyP0708]

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

[65536]

Никак не могу понять вечное массовое игнорирование Xdebug'а.

[AlexeyP0708]

Согласен.