PHPackages namelesscoder/typo3-cms-fluid-debug - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Debugging & Profiling](/categories/debugging) 4. / 5. namelesscoder/typo3-cms-fluid-debug ActiveTypo3-cms-extension[Debugging & Profiling](/categories/debugging) namelesscoder/typo3-cms-fluid-debug =================================== 1.1.1(7y ago)278341[1 issues](https://github.com/NamelessCoder/typo3-cms-fluid-debug/issues)1GPL-2.0-or-laterPHP Since Feb 2Pushed 7y ago2 watchersCompare [ Source](https://github.com/NamelessCoder/typo3-cms-fluid-debug)[ Packagist](https://packagist.org/packages/namelesscoder/typo3-cms-fluid-debug)[ RSS](/packages/namelesscoder-typo3-cms-fluid-debug/feed)WikiDiscussions master Synced 3d ago READMEChangelogDependencies (1)Versions (4)Used By (1) TYPO3 CMS Fluid Debugging Assistant =================================== [](#typo3-cms-fluid-debugging-assistant) This package contains overrides and additions to the standard Fluid debugging utility in TYPO3 CMS. It replaces the normal debugging ViewHelper with an improved version that solves several known problems. In addition to dumping variables it also allows you to insert xdebug break points in Fluid templates via a ViewHelper. The problems it solves ---------------------- [](#the-problems-it-solves) 1. The normal Fluid ViewHelper generates output either where it is used, or at the very top of the document before the doctype declaration. Either method has tremendous risk to destroy CSS rendering or be unreadable if used in a clipped or very tiny component. 2. When you debug properties of an object in Fluid, the Extbase property accessor is used. This means two things: first, the data you look at is *not* the actual data, it is the public gettable data which has properties associated with it. And two, it will only show you data that has a property, i.e. no virtual properties which only have getters. 3. Debugging a Fluid template means accessing a variable or ViewHelper expression twice, because the built-in debug ViewHelper *will not return the variable it debugs*. 4. You do not want debug statements in your production code, but sometimes you would like to leave them in templates and make assertions on the output they debug - but you can't, because the debug ViewHelper produces output. These problems are well known when debugging in Fluid. And this package solves all of them. Installation ------------ [](#installation) Install with Composer: ``` composer require namelesscoder/typo3-cms-fluid-debug ``` And if necessary, activate the `fluid_debug` extension in Extension Manager. No configuration is needed, but the package only has functionality when the site is not in Production context. Note that it is not enough to switch the context in the TYPO3 backend if you also defined `TYPO3_APPLICATION_CONTEXT` in your virtual host - the one defined in your virtual host takes priority, so make sure it is set to Development or Testing. The strategy ------------ [](#the-strategy) Instead of outputting content, the overridden debug ViewHelper instead delegates the output of variables to the JS console in your browser, by using PageRenderer to insert a call to a `console.log()` or other method, which receives a JSON object representation of the data you dump. In TYPO3 backend the ViewHelper dumps to the debugging console (which you can disable) and in CLI mode a regular `var_dump` is triggered (and xdebug break point if so configured in use). This means the ViewHelper is safe to use anywhere as it will never produce debug output inside the DOM body. An additional strategy is to allow the debugging ViewHelper to return the raw value it was asked to debug. This means you can use it as part of any inline expression to debug the value at that exact point. Consider the following example: ``` Long expression with debug in specific point: {myVariable -> f:debug() -> f:format.striptags() -> f:debug() -> f:format.nl2br()} Usage in argument value and arrays: Debugging an array costructed in Fluid while also passing that array: ``` Because the ViewHelper simply passes the value through, it can be left in place without causing rendering problems. This is a major difference compared to the native debugging ViewHelper which cannot be used this way without causing errors. The FE/BE/CLI sensitivity also means you get the least intrusive output possible; except on CLI where the standard var\_dump is used to produce markup-free dumps. Dumping strategy ---------------- [](#dumping-strategy) Contrary to the native TYPO3 CMS debug ViewHelper, the override dumps objects based primarily on the presence of getter methods which require no arguments - as opposed to basing it on the properties of a reflected object. Why this? The answer is that while Extbase dumping (which is what the native debug ViewHelper uses) is exceptionally good at dumping domain objects, it has shortcomings when the getter method you want to access doesn't have an associated property. Most prevalent example would be dumping a `File` resource which does not reveal all methods, including some of the most important API methods that are very useful in Fluid (example: metadata properties). So by dumping based not just on properties but by the presence of getter methods, with either the `get` or `has` or `is`prefixes, this dump reveals every property *that you can use in Fluid*, rather than just those that makes sense in an Extbase persistence context. Auto-suppressed in Production ----------------------------- [](#auto-suppressed-in-production) The package silences itself when the TYPO3 application context is set to Production. There are two main reasons for this: 1. By auto-suppressing, it means it is safe to deploy templates which contain debug statements. 2. Because debug statements output to `console.log()` or other, if you use acceptance testing with browser integration you can make assertions on variables passing through Fluid as part of your acceptance testing; variables which you don't see in the template output but are used to render it. So rather than as you normally would, remove debug statements or suppress them with `f:comment`, you can simply leave them in there - they cause no output in DOM body, they pass the debugged value through, and in Production content they are replaced with completely transparent versions of themselves. Usage details ------------- [](#usage-details) The package currently contains two ViewHelpers: - An override for `f:debug` which is semi-compatible (also uses tag content to read dump value) - A specialised alias with reduced arguments, `f:debug.break`, which instead of outputting to console will create a dynamic breakpoint for xdebug so you can inspect the state in your IDE. The `f:debug` override has the following arguments: - `value` which can be specified as argument value or is otherwise taken from tag content / child node - `title` which is a string you can use to identify the debug output - if not specified, the current template source code chunk and line/character number is shown if the template is not compiled (flush system cache to cause compiling). - `level` which is a string containing `log`, `warn` etc. - method name on the `console` object to be called. - `maxDepth` which is in integer, maximum number of levels to allow when traversing arrays/objects (note that infinite recursion is automatically prevented). - `silent` which is a boolean you can set to `1` if you want to suppress the output in console altogether. - `pass` which is a boolean you can set to `0` to not pass the dumped variable, useful if you for example have a separate `{object}` that would otherwise cause string conversion problems. - `break` which is a boolean you can set to `1` to cause an xdebug break point. Only happens if xdebug is installed. - `compile` which is a boolean you can set to `0` to disable compiling, letting you debug and break on the behavior the template has during parsing and compiling without having to flush caches repeatedly. And the reduced alias `f:debug.break` has the following arguments: - `value` exactly like above - `pass` exactly like above - `silent` like above, but with default set to `1` to suppress output - `break` like above, but with default set to `1` to always break - `compile` exactly like above In other words, `f:debug` is the main utility and `f:debug.break` is a customised alias which uses different default argument values, making it an ideal "insert breakpoint here" ViewHelper. Note about using breakpoints ---------------------------- [](#note-about-using-breakpoints) When you use break points with `f:debug.break` you don't just get the option of inspecting the variable you dump when the ViewHelper gets rendered - when break points are enabled, they trigger on the following events: - When the ViewHelper is initialized (when template is parsed, when ViewHelperNode is built in syntax tree) - When the ViewHelper is compiled to a PHP class (when you can dump for example the compiler's state) - When the ViewHelper is rendered (when you can inspect the actual value you want to dump, as well as other variables) A handful of key variables are extracted for easier reading in your IDE. These include the template source chunk, the line/character number, all current template variables, whether template is compiled, and so on. Note that you can also set `break="1"` on `f:debug` to cause an xdebug break point from that ViewHelper as well. **Important! Not all objects are possible to debug - when `f:debug` fails, `f:debug.break` and xdebug always works!** ### Health Score 33 — LowBetter than 75% of packages Maintenance19 Infrequent updates — may be unmaintained Popularity24 Limited adoption so far Community13 Small or concentrated contributor base Maturity65 Established project with proven stability Bus Factor1 Top contributor holds 88.9% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~136 days Total 4 Last Release 2614d ago ### Community Maintainers ![](https://www.gravatar.com/avatar/f5c01fb202269a6d9ba372c482874512d0246da99934592cdba1869a1776c4c1?d=identicon)[NamelessCoder](/maintainers/NamelessCoder) --- Top Contributors [![NamelessCoder](https://avatars.githubusercontent.com/u/2228052?v=4)](https://github.com/NamelessCoder "NamelessCoder (8 commits)")[![bigbozo](https://avatars.githubusercontent.com/u/621152?v=4)](https://github.com/bigbozo "bigbozo (1 commits)") ### Embed Badge ![Health badge](/badges/namelesscoder-typo3-cms-fluid-debug/health.svg) ``` [![Health](https://phpackages.com/badges/namelesscoder-typo3-cms-fluid-debug/health.svg)](https://phpackages.com/packages/namelesscoder-typo3-cms-fluid-debug) ``` ### Alternatives [symfony/stopwatch Provides a way to profile code 2.8k387.2M918](/packages/symfony-stopwatch)[fruitcake/laravel-debugbar PHP Debugbar integration for Laravel 19.1k662.9k29](/packages/fruitcake-laravel-debugbar)[spatie/ignition A beautiful error page for PHP applications. 510147.6M69](/packages/spatie-ignition)[jokkedk/webgrind Webgrind is a Xdebug profiling web frontend in PHP5. It implements a subset of the features of kcachegrind and installs in seconds and works on all platforms. For quick'n'dirty optimizations it does the job. 3.3k193.0k](/packages/jokkedk-webgrind)[koriym/printo An object graph visualizer. 1421.8M2](/packages/koriym-printo)[soloterm/dumps A Laravel command to intercept dumps from your Laravel application. 125285.7k3](/packages/soloterm-dumps) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)