.. index:: single: VarDumper single: Components; VarDumper The VarDumper Component ======================= The VarDumper component provides mechanisms for extracting the state out of any PHP variables. Built on top, it provides a better ``dump()`` function that you can use instead of :phpfunction:`var_dump`. Installation ------------ .. code-block:: terminal $ composer require --dev symfony/var-dumper .. include:: /components/require_autoload.rst.inc .. note:: If using it inside a Symfony application, make sure that the DebugBundle has been installed (or run ``composer require --dev symfony/debug-bundle`` to install it). .. _components-var-dumper-dump: The dump() Function ------------------- The VarDumper component creates a global ``dump()`` function that you can use instead of e.g. :phpfunction:`var_dump`. By using it, you'll gain: * Per object and resource types specialized view to e.g. filter out Doctrine internals while dumping a single proxy entity, or get more insight on opened files with :phpfunction:`stream_get_meta_data`; * Configurable output formats: HTML or colored command line output; * Ability to dump internal references, either soft ones (objects or resources) or hard ones (``=&`` on arrays or objects properties). Repeated occurrences of the same object/array/resource won't appear again and again anymore. Moreover, you'll be able to inspect the reference structure of your data; * Ability to operate in the context of an output buffering handler. For example:: require __DIR__.'/vendor/autoload.php'; // create a variable, which could be anything! $someVar = ...; dump($someVar); // dump() returns the passed value, so you can dump an object and keep using it dump($someObject)->someMethod(); By default, the output format and destination are selected based on your current PHP SAPI: * On the command line (CLI SAPI), the output is written on ``STDOUT``. This can be surprising to some because this bypasses PHP's output buffering mechanism; * On other SAPIs, dumps are written as HTML in the regular output. .. tip:: You can also select the output format explicitly defining the ``VAR_DUMPER_FORMAT`` environment variable and setting its value to either ``html`` or ``cli``. .. note:: If you want to catch the dump output as a string, please read the :doc:`advanced documentation ` which contains examples of it. You'll also learn how to change the format or redirect the output to wherever you want. .. tip:: In order to have the ``dump()`` function always available when running any PHP code, you can install it globally on your computer: #. Run ``composer global require symfony/var-dumper``; #. Add ``auto_prepend_file = ${HOME}/.composer/vendor/autoload.php`` to your ``php.ini`` file; #. From time to time, run ``composer global update symfony/var-dumper`` to have the latest bug fixes. .. tip:: The VarDumper component also provides a ``dd()`` ("dump and die") helper function. This function dumps the variables using ``dump()`` and immediately ends the execution of the script (using :phpfunction:`exit`). .. _var-dumper-dump-server: The Dump Server --------------- The ``dump()`` function outputs its contents in the same browser window or console terminal as your own application. Sometimes mixing the real output with the debug output can be confusing. That's why this component provides a server to collect all the dumped data. Start the server with the ``server:dump`` command and whenever you call to ``dump()``, the dumped data won't be displayed in the output but sent to that server, which outputs it to its own console or to an HTML file: .. code-block:: terminal # displays the dumped data in the console: $ php bin/console server:dump [OK] Server listening on tcp://0.0.0.0:9912 # stores the dumped data in a file using the HTML format: $ php bin/console server:dump --format=html > dump.html Inside a Symfony application, the output of the dump server is configured with the :ref:`dump_destination option ` of the ``debug`` package: .. configuration-block:: .. code-block:: yaml # config/packages/debug.yaml debug: dump_destination: "tcp://%env(VAR_DUMPER_SERVER)%" .. code-block:: xml .. code-block:: php // config/packages/debug.php $container->loadFromExtension('debug', [ 'dump_destination' => 'tcp://%env(VAR_DUMPER_SERVER)%', ]); Outside a Symfony application, use the :class:`Symfony\\Component\\VarDumper\\Dumper\\ServerDumper` class:: require __DIR__.'/vendor/autoload.php'; use Symfony\Component\VarDumper\Cloner\VarCloner; use Symfony\Component\VarDumper\Dumper\CliDumper; use Symfony\Component\VarDumper\Dumper\ContextProvider\CliContextProvider; use Symfony\Component\VarDumper\Dumper\ContextProvider\SourceContextProvider; use Symfony\Component\VarDumper\Dumper\HtmlDumper; use Symfony\Component\VarDumper\Dumper\ServerDumper; use Symfony\Component\VarDumper\VarDumper; $cloner = new VarCloner(); $fallbackDumper = \in_array(\PHP_SAPI, ['cli', 'phpdbg']) ? new CliDumper() : new HtmlDumper(); $dumper = new ServerDumper('tcp://127.0.0.1:9912', $fallbackDumper, [ 'cli' => new CliContextProvider(), 'source' => new SourceContextProvider(), ]); VarDumper::setHandler(function ($var) use ($cloner, $dumper) { $dumper->dump($cloner->cloneVar($var)); }); .. note:: The second argument of :class:`Symfony\\Component\\VarDumper\\Dumper\\ServerDumper` is a :class:`Symfony\\Component\\VarDumper\\Dumper\\DataDumperInterface` instance used as a fallback when the server is unreachable. The third argument are the context providers, which allow to gather some info about the context in which the data was dumped. The built-in context providers are: ``cli``, ``request`` and ``source``. Then you can use the following command to start a server out-of-the-box: .. code-block:: terminal $ ./vendor/bin/var-dump-server [OK] Server listening on tcp://127.0.0.1:9912 DebugBundle and Twig Integration -------------------------------- The DebugBundle allows greater integration of this component into Symfony applications. Since generating (even debug) output in the controller or in the model of your application may just break it by e.g. sending HTTP headers or corrupting your view, the bundle configures the ``dump()`` function so that variables are dumped in the web debug toolbar. But if the toolbar cannot be displayed because you e.g. called ``die()``/``exit()``/``dd()`` or a fatal error occurred, then dumps are written on the regular output. In a Twig template, two constructs are available for dumping a variable. Choosing between both is mostly a matter of personal taste, still: * ``{% dump foo.bar %}`` is the way to go when the original template output shall not be modified: variables are not dumped inline, but in the web debug toolbar; * on the contrary, ``{{ dump(foo.bar) }}`` dumps inline and thus may or not be suited to your use case (e.g. you shouldn't use it in an HTML attribute or a ``