Project

General

Profile

Actions

Bug #72950

closed

<f:debug> is broken when using it inside of flux / fluid content

Added by Tobias Gülzow over 8 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Fluid
Target version:
-
Start date:
2016-01-26
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

I'm not sure if this is the right place to report this, because it might be an flux or fluidcontent issue . . .

When using <f:debug> in the backend, inside a flux content element, the debug output is broken.

Typo3 version
Typo3 7.6.2

Extensions:
vhs 2.4.0
builder 1.1.0
flux 7.3.0
fluidcontent 4.4.0

How to reproduce:
1.) Set up a Typo3 7.6.2
2.) Install the extensions above
3.) Use Builder to kickstart a contentprovider (Include content templates)
4.) Activate the extension and include it's typoscript setup
5.) Add <f:debug>{_all}</f:debug> inside the <f:section name="Configuration"> of the Example.html file
6.) Create a new example element in one of the pages

Tobi


Files

Bugreport.png (15.8 KB) Bugreport.png Screenshot Tobias Gülzow, 2016-01-26 15:55
Actions #1

Updated by Claus Due over 8 years ago

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.

Actions #2

Updated by Tobias Gülzow over 8 years ago

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

Actions #3

Updated by Mathias Brodala over 8 years ago

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

Actions #4

Updated by Tobias Gülzow over 8 years ago

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

Actions #5

Updated by Claus Due over 8 years ago

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.

Actions #6

Updated by Tobias Gülzow over 8 years ago

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

Then please close this issue.

Tobi

Actions #7

Updated by Wouter Wolters over 8 years ago

  • Status changed from New to Closed

Closed as requested.

Actions

Also available in: Atom PDF