TYPO3 Core

This is by design - or rather, an expected failure. It happens because f:debug produces output and the Configuration section is not intended for producing any output. It is made further complicated by the fact that f:debug behaves differently in the front- and backend. That being said, f:debug should when used in the backend produce debug log messages instead of output (but if you render that same Configuration section in the frontend, output is produced and it breaks).

There is no way to avoid this except to remove your f:debug statements before attempting to render the element in the frontend. If you need to debug variables in a frontend context, the "Main" section (or whichever section your Layout renders; or the Layout itself) would be the place to add your f:debug statement.

Hi Claus

First, let me thank you for your fast reply. That was really fast :-)

This is by no means a showstopper. The info is there and it's readable.
Should we change this into "Feature request" and "Could have"?

Tobi

How about <f:debug inline="TRUE">...</f:debug>?

The inline option lets the DebuggerUtility return the output, instead of simply echo'ing it. I'm afraid, that only flux-elements will get rendered via fluid here.

The problem (as far as I can see it) is that the DebuggerUtility simply starts the output via echo, at a time when typo3 has not had the opportunity to send anything to the browser.
Strangely, it does not echo the stylesheet (or my browser is at fault here).

Another problem is, that when a debugger starts the output, the underlying cms may not get the chance to set any cookies.

. . . ummm, shall I look deeper into this?

Tobi

I would rather close this as a combination of how Fluid works by design and how Flux uses Fluid in this particular case. Fluid's f:debug outputs immediately for a good reason (output is there also if exceptions get thrown) and using inline="1" won't fix it - it will simply suppress the output because Flux will ignore all output of the Configuration section (instead uses variables built into the ViewHelperVariableContainer during execution).

In other words: this is the exact same as if you threw a var_dump in there. It would break cookie setting etc. in exactly the same way and should never, ever be used in production for obvious reasons. You will only ever face this issue while debugging and when debugging you should not expect output that contains debug information to also be a valid response, e.g. JSON or XML or merely proper HTML.

Should you need more advanced methods of debugging which will not intervene with output then I suggest writing a custom ViewHelper that does things like logging the data or write dump files. You should still avoid this in production.

Recommend closing this issue.

Debugging in production? Never ever, this will only lead to trouble.

Then please close this issue.

Tobi