16 февраля 2023 в 12:35
Всем привет. Изучаю потихоньку друпал 9/10. И вот незадача: dpm() выводит данные, только если вызывать ее в коде файла my_theme.theme. Если вызывать ее в коде my_module.module то ничего не происходит. Данные не выводятся, ошибок при этом нет. Сам кастомный модуль рабочий, с помощью print_r() та же переменная выводится. Но отладочные функции devel в модуле почему-то не работают.
Это у меня что-то недонастроено (что?), или он реально только в теме теперь пашет? На семерке выводился откуда угодно.
Комментарии
Там в настройках девела можно выбирать бэкенд для вывода сообщений. Пощелкайте разные варианты. А вообще лучше освоить xdebug и забыть про dpm как про страшный сон
почему страшный? Вполне удобный инструмент, вроде бы. Был в семерке, во всяком случае.
Потому что с ним можно производить ну совсем какую-то примитивную отладку. А когда нужно полазить по объекту, посмотреть его свойства да и вообще пройти код по шагам, то тут без xdebug не обойтись. Проще сразу освоить нормальный инструмент и дальше спокойно работать
довелось когда-то работать с xdebug - там какой-то вырви глаз оранжевый дизайн был. И вроде как можно было подправить его стилями, но это ж заморочка... И для каждого сайта нужно было этот файлик со стилями тащить... Может уже давно все изменилось, конечно...
А умеет он выводить многомерные массивы/объекты в сложенном виде, как это делает dpm? Раскрываешь потом нужные ветки и ищешь что надо... Или сразу простыню вываливает как var_dump или print_r и ищи-свищи в ней?
xdebug - это по сути консольное приложение, у него нет своего "дизайна". Дизайн может зависить от IDE где xdebug используется
Для примера вот картинка из интернета как происходит отладка в PhpStorm. Мне просто лень запускать какой-нибудь проект чтобы скриншот сделать
Конечно. И при этом еще и не тормозит как dpm. На скриншоте выше. Разворачиваешь любой массив/объект и изучаешь. Быстро, удобно, комфортно
А без IDE юзать xdebug не получится?
Может и можно, но зачем? Если нет лицензии на PhpStorm, можно использовать бесплатный vscode
да как-то всегда хватало notepad++
ну ладно. Может и до ide доберусь. А пока что хочется сделать просто красивый вывод var_dump. Коли уж с dpm засада. С xdebug это возможно. Но после инициализации xdebug в docksal, рестарте проекта и очистки кэша получаю ошибку:
Xdebug: [Step Debug] Could not connect to debugging client. Tried: 192.168.64.1:9000 (through xdebug.client_host/xdebug.client_port) :-(Не подскажете, что тут можно сделать?
Подскажу как убрать это сообщение, но завтра. А сейчас скажу, что это всего лишь варнинг и он работе не мешает
сообщение убрать удалось (в php.ini xdebug.log_level = 0) Но var_dump красивым не стал. Значит что-то еще настраивать надо.
Ничего не помогает.
Но вряд ли дело в этом. Ведь из файла .theme вывод есть. А нет именно из модуля.
обычно использую kint() а не dpm(), только надо подтянуть предварительно либо модулем devel_kint_extras либо просто через composer
xdebux пользуюсь реже, хотя постоянно включен. xdebux у меня обычно работает дольше ) , но иногда без него никак...
Kint выводит. Правда не kint() - этот молчит. А Kint::dump().Вывел переменую. Но после этого сайт сразу отключается.
RuntimeException: Failed to start the session because headers have already been sent
by "/var/www/vendor/kint-php/kint/src/Kint.php" at line 581.
in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start()
(line 132 of /var/www/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).
Как это исправить?
kint не работает, dpm не работает, xdebug не работает. Нет счастья в жизни.
точнее, kint() работает, как и dpm() только в файле my_theme.theme.
В файле my_module.module не работает.
так наверно установить и настроить.
/admin/config/development/devel выбрать kint
composer require kint-php/kint --dev
все сделано. И не работает только в файле модуля. Точнее, модулей.
Глупый вопрос задам: а в этом файле вообще хоть что-то (другой код) работает? То есть модуль точно включен, нет никаких опечаток в имени файла? И тот фрагмент кода, в котором осуществляется вызов dpm точно исполняется?
Модуль включен. Тестирую на простейшем коде
$a = [1,2,3];
print_r($a), var_damp($a) - массив выводят.
Правда при включенном xdebug var_dump() не становится форматированным. То есть выводит просто в строку, что конечно не вариант при больших многомерных массивах.
dpm(), kint() - это все не работает. Ошибок не выдает никаких. Просто ничего не выводит.
Если не юзать devel, но юзать kint в чистом виде
Kint::dump($a);
то массив выводится и отформатированный, красивый, но сайт после этого выдает ошибку, что заголовки уже посланы.
Проблема с dpm наблюдается только в файлах модулей (любых). В файле .theme - все отрабатывается как надо.
kint независимо от того, где выводится переменная, выдает ошибку уже посланных заголовков.
Kint::dump($a); работает без ошибок, если отлаживать не авторизуясь на сайте.
Чудеса. Лично я использую Devel Debug Log (ddl). Попробуйте - вдруг заработает.
Devel Debug Log требует devel 4. А с drupal 10 работает devel 5. Вобщем, не устанавливается ddl
Упс. Еще один повод повременить с D10.
Проблема с dpm в том, что она (как и код, который отлаживается) должна быть внутри какого-нибудь хука или функции, которая потом как-то подхватывается системой.
Вот внутри такого кода dpm работает как надо
<?phpfunction my_module_preprocess_page(&$variables){
$b=[1,2,3];
dpm($b);
}?>
В семерке работало и без функций.
А что ты хотел дебажить вне функций?))
я просто смотрел как работают некоторые функции api в 10-ке. В частности захотелось программно вывести дерево таксономии. Результат кода выводил для начала в dpm. А он не выводился. В семерке dpm при тех же условиях работал.
Написать код лишь бы где, чтобы он только выполнился - это не лучший вариант. Если нужно смотреть, как что-то работает, лучше всего сделать свой контроллер и там в нём вызывать всё, что угодно и смотреть это на странице контроллера.
для понимания того, что конкретно выводит та или иная функция - все равно где выводить.
А в полноценном модуле - да, я так понимаю, крайне важно что и где должно размещаться. Контроллер - это файл в src/Controller? В котором подразумевается размещать всю логику, так? А что тогда размещают в файле .module?
В файле .module размещают хуки и другие глобально доступные функции. В контроллере размещают только ту логику, которая отвечает за формирование ответа конкретной страницы.
Что касается вот этого:
Оно то конечно всё равно, особенно когда не жалко убить целую неделю на то, чтобы понять, почему функция, написанная в рандомном месте срабатывает, когда захочет, или вообще никогда не срабатывает.
А создать свой контроллер для экспериментов полезно тем, что там можно делать всё что угодно, при этом не опасаясь сломать всё остальное. Кроме того, потом этот контроллер можно просто удалить и забыть о нём. А если выводить всё подряд, где ни попадя, потом это входит в привычку. После таких разработчиков открываешь на сайте консоль, а там куча неприличных слов выводится.
Пока не очень понятно. Можете привести парочку примеров, когда в модуле необходим контроллер?
Например, если надо создать какую-то страницу, на которой хочется вывести что-нибудь через dpm()
А вообще, контроллер - это то, что в семёрке делалось через hook_menu