Не работает dump symfony

Компонент VarDumper (сброс переменной)¶

Установка¶

Alternatively, you can clone the https://github.com/symfony/var-dumper repository.

If you install this component outside of a Symfony application, you must require the vendor/autoload.php file in your code to enable the class autoloading mechanism provided by Composer. Read this article for more details.

Если вы используете его внутри приложения Symfony, убедитесь, что был установлен DebugBundle (или запустите composer require symfony/debug-bundle , чтобы установить его).

Функция dump()¶

Компонент VarDumper создаёт глобальную функцию dump() , которую вы можете использовать вместо, например. var_dump . Используя её, вы получаете:

• Специализированный просмотр по объектам и источникам, чтобы, к примеру, отфильтровать внутренние объекты Doctrine при сбросе одной сущности прокси, или получить больше информации об открытых с помощью stream_get_meta_data файлах;
• Конфигурируемые форматы вывода: вывод HTML или цветной командной строки;
• Возможность сбрасывать внутренние ссылки, мягкие (объекты или источники) или жёсткие ( =& в свойствах массивов или объектов). Повторяемое появление одного и того же объекта/масива/истоничка не будут больше появляться снова и снова. Более того, вы сможете исследовать структуру ссылок ваших данных;
• Возможность оперировать в контексте обработчика буферизации вывода.

По умолчанию, формат вывода и направление выбираются исходя из вашего текущего PHP SAPI:

• В командной строке (CLI SAPI), вывод пишется в STDOUT . Это может быть удивительно для некоторых, так как это обходит механизм буферизации вывода PHP;
• В других SAPI, сбросы пишутся в виде HTML в обычном выводе.

Если вы хотите поймать вывод сброса в виде строки, пожалуйста, прочтите продвинутую документацию , которая содержит такие примеры. Вы также узнаете, как изменять формат или перенаправлять вывод туда, куда вам нужно.

Для того, чтобы функция dump() всегда была доступна при выполнении любого PHP кода, вы можете установить её на вашем компьютере глобально:

1. Запустите composer global require symfony/var-dumper ;
2. Добавьте auto_prepend_file = $/.composer/vendor/autoload.php к вашему файлу php.ini ;
3. Иногда запускайте composer global update symfony/var-dumper , чтобы иметь последние исправления багов.

Компонент VarDumper также предоставляет функцию dd() (“dump and die” — “сбрось и умри”). Эта функция отображает переменные используя dump() и сразу прекращает исполнение скрипта (используя функцию PHP exit ).

New in version 4.1: Метод dd() появился в Symfony 4.1.

Сервер дампов¶

New in version 4.1: Сервер дампов появился в Symfony 4.1.

Функция dump() выводит своё содержимое в то же окно браузера или консольный терминал, что и ваше приложение. Иногда смешение настоящего вывода с выводом отладочной информации может запутывать. Поэтому этот компонент предоставляет сервер для сбора всей отладочной информации.

Запустите сервер командой server:dump и когда вы будете вызывать dump() , отладочная информация не будет отображаться в потоке вывода, а отправится на этот сервер, который будет отображать это в своей конслоли или HTML-файле:

Внути приложения Symfony, вывод дамп-сервера настраивается с помощью настройки dump_destination пакета debug .

Интеграция DebugBundle и Twig¶

DebugBundle позволяет большую интеграцию компонента в приложения Symfony.

Так как генрировние вывода (даже отладки) в контроллере или модели вашего приложения может просто его сломать (например, отправка HTTP заголовков или нарушение вашего просмотра), пакет конфигурирует функцию dump() , чтобы переменные сбрасывались в панели инструментов веб-отладки.

Но если панель инструментов нельзя отобразить так как вы, к примеру, вызвали die() / exit() / dd() или возникла фатальная ошибка, тогда дампы пишутся в обычном потоке вывода.

В шаблоне Twig доступны две конструкции для сброса переменной. Выбор между двумя в основном зависит от ваших личных предпочтейни, и всё же:

• <% dump foo.bar %>стоит использовать, когда исходный вывод шаблона не стоит изменять: переменные сбрасываются не встроено, а в панели инструментов веб отладки;
• и наоборот, << dump(foo.bar) >> сбрастывает встроено и поэтому может подходить или не подходить в вашем случае (например, не стоит использовать его в атрибуте HTML или теге ).

Это поведение можно изменить, сконфигурировав опцию debug.dump_destination . Прочтите больше об этом и других опциях в справочнике конфигурации DebugBundle .

Если сброшенное содержание сложное, рассмотрите использование локальное поле поиска, чтобы найти определённые переменные или значения. Для начала, нажмите где угодно в сброшенном содержании, а потом нажмите Ctrl. + F или Cmd. + F , чтобы появилось локальное поле поиска. Все общие сокращения для поиска результата поддерживаются ( Ctrl. + G или Cmd. + G , F3 , и др.) Когда закончите, нажмите Esc. , чтобы спрятать поле.

Использование компонента VarDumper в вашем наборе тестов PHPUnit¶

Компонент VarDumper предоставляет a trait , который может помочь написать некоторые из ваших тестов для PHPUnit.

Это предоставит вам два новых утверждения:

assertDumpEquals() верифицирует, чтобы сброс переменной, данный в виде второго аргументы, соответствовал ожидаемому сбросу, предоставленному в качестве первого аргумента. assertDumpMatchesFormat() такой же, как и предыдущий метод, но принимает заполнители в ожидаемом сбросе, основанном на методе assertStringMatchesFormat() , предоставленном PHPUnit.

New in version 4.1: Возможность передачи нестроковых переменных в качестве первого аргумента assertDumpEquals() была представлена в Symfony 4.1.

Примеры сброса и вывод¶

Для простых переменных, чтение вывода должно быть прямолинейным. Вот некоторые примеры, отображающие первую переменную, определённую в PHP, а потом его представление сброса:

Серая стрелка — это кнопка переключателя для показа / скрытия детей встроенных структур.

#14 это внутренний объект для обработки. Он позволяет сранвивать два последовательных сброса одного и того же объекта.

Источник

Шаг 5: Поиск и устранение неисправностей

Настройка проекта также подразумевает наличие правильных инструментов для отладки.

Установка дополнительных зависимостей¶

Помните, наш проект создан с очень небольшим количеством зависимостей: без шаблонизатора, без инструментов для отладки, без логера. Такой подход позволяет добавить другие зависимости только тогда, когда они вам нужны. Зачем вам шаблонизатор, если вы разрабатываете HTTP API или CLI-инструмент?

Как добавить больше зависимостей? Через Composer. Помимо «обычных» Composer-пакетов, мы будем работать с двумя «специальными» видами пакетов:

• Компоненты Symfony: пакеты с базовой функциональностью и низкоуровневыми абстракциями, необходимые большинству приложений (маршрутизация, консоль, HTTP-клиент, почтовый клиент, кеш и т.д.);
• Бандлы Symfony: пакеты, которые добавляют высокоуровневую функциональность или предлагают интеграцию со сторонними библиотеками (эти бандлы в основном разрабатываются сообществом).

Для начала давайте добавим Symfony Profiler, который поможет сэкономить много времени в поиске источника проблемы:

profiler — это псевдоним для пакета symfony/profiler-pack .

Псевдонимы — это не функция самого Composer, а концепция Symfony, чтобы облегчить нам жизнь. Псевдонимы — это ярлыки для популярных Composer-пакетов. Вашему приложению нужен ORM? Установите orm . Хотите разработать API? Установите api . Псевдонимы автоматически преобразуются в один или несколько обычных Composer-пакетов. Псевдонимы назначаются основной командой Symfony.

Ещё одна интересная особенность — можно не указывать вендора symfony в имени пакета. Поэтому, например, вместо symfony/cache набирайте cache .

Мы уже упоминали Composer-плагин symfony/flex . Псевдонимы — лишь одна из его функциональных возможностей.

Понимание окружений Symfony¶

Вы заметили флаг —dev при использовании команды composer req ? Поскольку Symfony Profiler имеет смысл использовать во время разработки, то не стоит устанавливать его в продакшене.

Symfony поддерживает создание окружений. По умолчанию есть три окружения с возможностью добавить дополнительные: dev , prod и test . Все окружения используют один и тот же код, но имеют разные конфигурации.

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

Изменяя значение переменной окружения APP_ENV можно переключаться с одного окружения на другое.

Во время развёртывания на SymfonyCloud, окружение (сохранённое в APP_ENV ) автоматически переключится на prod .

Управление конфигурациями окружений¶

Переменная APP_ENV может быть задана с помощью «настоящих» переменных окружения в терминале:

Переменные окружения, такие как APP_ENV , рекомендуется явно определять на продакшен-серверах. Однако в процессе разработки установка таким образом множество переменных окружения может стать утомительной. Поэтому вместо этого определите их в файле .env .

При создании проекта был автоматически сгенерирован файл .env :

Благодаря использованию рецептов Symfony Flex, любой пакет может добавить свои переменные окружения в этот файл.

Файл .env хранится в репозитории и содержит значения по умолчанию для продакшена. Вы можете задать свои значения, создав файл .env.local . Этот файл не хранится в репозитории, поэтому изначально игнорируется в .gitignore .

Никогда не храните конфиденциальную информацию в этих файлах. Позже мы рассмотрим, как управлять такими видами данных.

Логирование всех действий¶

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

Установим инструменты отладки только в окружении разработчика:

Изучение средств отладки Symfony¶

При обновлении главной страницы в нижней части экрана должна появиться панель отладки:

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

Нажмите на маленький восклицательный знак и вы увидите сообщение «настоящего» исключения в логах профилировщика Symfony. Если вы хотите увидеть трассировку стека, нажмите на ссылку «Exception» в левом меню.

Когда возникает проблема с кодом, вы увидите похожую страницу об ошибке со всей необходимой информацией для отладки:

Уделите немного времени и поизучайте данные в профилировщике Symfony, нажимая по разным ссылкам.

Логи весьма полезны при отладке. В Symfony есть удобная команда для отображения последних строк всех логов (веб-сервера, PHP и вашего приложения):

Проведем небольшой эксперимент. Откройте public/index.php и сделайте ошибку в PHP-коде (например, добавьте foobar посередине кода). Обновите страницу в браузере и понаблюдайте за логом:

Логи отображаются разными цветами, чтобы привлечь ваше внимание к ошибкам.

Symfony-функция dump() — ещё один замечательный помощник во время отладки. Она глобально доступна и отображает значение переменных в удобном интерактивном формате.

Временно измените файл public/index.php , чтобы вывести объект Request:

После обновления страницы обратите внимание на новую иконку с мишенью. Она позволит вам посмотреть детали объекта. Щёлкните по ней, чтобы перейти на отдельную страницу с полной информацией об объекте:

Отмените это изменение кода перед коммитом других изменений, которые были сделаны на этом шаге:

Настройка среды разработки¶

В локальном окружении разработки при генерации исключения Symfony отображает страницу с сообщением исключения и его трассировкой. К отображаемому пути файла в трассировке добавляется ссылка, кликнув на которую можно открыть файл на нужной строке прямо в вашей IDE. Но чтобы воспользоваться этой возможностью, сначала вам нужно настроить IDE. Symfony поддерживает множество разных IDE; я использую Visual Studio Code для данного проекта:

Ссылка в имени файла появляется не только при генерации исключения. Так, например, контроллер на панели отладки может стать кликабельным, если настроить IDE.

Отладка в продакшене¶

Отладка на продакшен-серверах всегда сложнее. К примеру, в таком случае у вас нет доступа к профилировщику Symfony. А в логах не так много подробной информации. Но всё же можно посмотреть последние записи логов:

Вы даже можете подключиться через SSH из веб-контейнера:

Не бойтесь — вы не сможете так просто всё сломать. Большая часть файловой системы доступна только для чтения. Поэтому сделать срочное исправление прямо на продакшене не получится. Однако вы узнаете про гораздо более подходящий способ сделать это позже в книге.

• « Previous Шаг 4: Выбор методологии разработки
• Next » Шаг 6: Создание контроллера

This work, including the code samples, is licensed under a Creative Commons BY-NC-SA 4.0 license.

Источник

Dump doesn’t work with console application #29765

Comments

elanmailerag commented Jan 3, 2019 •

Symfony version: 4.2.0

Description
I called my command from a Controller as written in documentation here . And I used dump function.
But for some reason there’s no output, dump is not working. And if I’d use print_r or var_dump they work fine. If I use dump before running application, it works fine.

How to reproduce

The text was updated successfully, but these errors were encountered:

ogizanagi commented Jan 3, 2019

It probably relates to the Symfony\Component\HttpKernel\EventListener\DumpListener which, once the command is started, replaces the VarDumper handler used, so the CliDumper is used instead of the html & dump data collector set earlier.

I’m not sure we should qualify this as a bug nor if we should still promote this way of executing commands from a controller in the documentation.

yceruto commented Jan 3, 2019 •

@elanmailerag try VarDumper::setHandler(null) before dump($content) .

ro0NL commented Jan 4, 2019

It probably relates to the Symfony\Component\HttpKernel\EventListener\DumpListener which, once the command is started, replaces the VarDumper handler used,

shouldnt we cleanup/restore on terminate then?

ogizanagi commented Jan 4, 2019

shouldnt we cleanup/restore on terminate then?

More or less what I started in ogizanagi@23a80bb for #26696 (but missing the setPreviousHandler call in DumpListener )

ro0NL commented Jan 4, 2019 •

you can store the previous handler in dumplistener no? Returned by

VarDumper :: setHandler ( static function ( $ var ) use ( $ cloner , $ dumper , $ connection ) <

then restore it on terminate if the current handler is still the specialized one

ogizanagi commented Jan 4, 2019

For this issue precisely, yes. At the time this was driven by a concrete use-case with a different issue. Restoring previously configured handler from tests when running a functional test.

Simperfit commented Apr 7, 2019

Is there something to do in here ?

pueppiblue commented May 26, 2019 •

It probably relates to the Symfony\Component\HttpKernel\EventListener\DumpListener which, once the command is started, replaces the VarDumper handler used, so the CliDumper is used instead of the html & dump data collector set earlier.

I’m not sure we should qualify this as a bug nor if we should still promote this way of executing commands from a controller in the documentation.

@Simperfit
I’d concur with @ogizanagi.
Inside a symfony application we won’t be able to dump to WDT anymore after running a command (from
inside a controller) with Application::run().
Either the original Handler should be restored on ConsoleEvents::TERMINATE event as attempted in
[ogizanagi/symfony@23a80bb] or the documentation How to call a command from Controller should be pointing out the changed var-dumper behavior.
It is possible to run a command via the process component though. This does not touch the var-dumper behavior. Maybe rather this should be promoted as a way of running commands from a controller.

carsonbot commented Dec 19, 2020

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

carsonbot commented Jan 2, 2021

Could I get a reply or should I close this?

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник