This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » eZ Publish 5 Platform » Debug output in Frontend?

Debug output in Frontend?

Debug output in Frontend?

Wednesday 26 September 2012 9:55:12 am - 17 replies

Hi dear forum members,

I'm playing with eZ5-Installation and I'm trying to activate the debug output in frontend. All the settings, which I can change in site.ini or site.ini.append.php activate or deactivate debug output only in admin.... Is there any possibility to activate it for frontend?

Wednesday 26 September 2012 10:04:04 am


I don't know if the debug output system is different in eZ5, but for the previous verisons, you can change the debug output settings directly in the administration interface (in the admin siteaccess). I suggest you to read this good article :


Wednesday 26 September 2012 10:10:53 am

Hi Paul,

thank you for your reply. Yes, I know that possibility, but as I wrote before, everything what I try has effect only in admin, not in frontend...

Modified on Wednesday 26 September 2012 1:56:00 pm by Elena S.

Wednesday 26 September 2012 2:30:00 pm

Hi Elena. This is normal when using eZ Publish 5 since there is no debug output any more. Instead we're using the Symfony web profiler toolbar which appears at the bottom of your screen if you are in debug mode (using index_dev.php).

AFAIK, Gaetano has a project of implementing data collectors for legacy debug stuff (e.g. eZDebug) in order to display them in the web profiler. The same approach is explained on YMC blogpost about data collectors and eZ Publish 5.

Wednesday 26 September 2012 3:14:19 pm

Hi Jérôme, thank you very much for your answer, that is exactly what I thought had happened. I'm very thankful for your affirmation happy.gif Emoticon

Thursday 27 September 2012 10:45:56 am

Hi Jérôme,

I found yesterday out, that in the ezdebug - Class in eZ5 (app/ezpublish_legacy/lib/ezutils/classes/ezdebug.php), in the function "printReport" there is a call to printReportInternal - function where two different parameters are passed as one:

$report = $debug->printReportInternal( $as_html, $returnReport & $newWindow , $allowedDebugLevels, $useAccumulators, $useTiming, $useIncludedFiles );

$returnReport & $newWindow

and so it makes it impossible to  get the report delivered to a variable and not to print it out immediately, setting $returnReport to true and $newWindow to false....

is it a mistake? is there is other possibility to get that debug report delivered to a variable?

Best wishes, Elena

Thursday 27 September 2012 11:06:04 am

Hi Elena

Why don't you call printReportInternal() directly then ? happy.gif Emoticon

I'm guessing here that you're on your way to develop your first bundle for eZ Publish 5 aren't you ? blunk.gif Emoticon

Thursday 27 September 2012 11:11:21 am

Hi Jérôme,

yes, you are guessing right blunk.gif Emoticon

Well, calling printReportInternal delivers me a little bit different output than calling printReport...

But both of them deliever far too little output in comparison with frontend output which I know from eZ 4. But as in eZ 5 the frontend debug output is disabled, I can not compare, if that what I get is right or not sad.gif Emoticon

Thursday 27 September 2012 11:19:48 am

This might be because you're not setting the right values to the method's arguments. You might want to check how debug output is displayed in legacy kernel blunk.gif Emoticon.

Thursday 27 September 2012 11:20:56 am

oh, thank you, I will take a look at it immediately!

Thursday 27 September 2012 1:05:59 pm

@Elena ob_start is probably your a good friend here

Thursday 27 September 2012 1:23:57 pm

Quote from Gaetano Giunta :

@Elena ob_start is probably your a good friend here

Actually this is already done by eZDebug::printReportInternal() blunk.gif Emoticon

Thursday 27 September 2012 2:50:41 pm

so, now I tried out all possible settings and I think that I can't get really much more Debug-infos inside of the Symfony profiler as eZ-Debug debugs only legacy things.

For example it recongnizes only old templates, not the twig-templates and alone that prevents already many infos to appear.

so for now it's not a lot, what I have, but it is shown on a right place and comes from a right place blunk.gif Emoticon

Thursday 27 September 2012 3:49:11 pm

@jv doh!

@Elena any special things that you might want traced from the new stack which are not already displayed in the sf standard profiler?

Thursday 27 September 2012 4:07:44 pm

@Elena: True (at least for now), but that's a good start. I hope you'll contribute it somehow happy.gif Emoticon.

Tuesday 02 October 2012 11:42:29 am

Hi Jérôme,

I've written a blog post to that topic

hope it is interesting happy.gif Emoticon

best wishes


Modified on Tuesday 02 October 2012 11:42:51 am by Elena S.

Tuesday 02 October 2012 12:16:29 pm

Hi Elena

It's definitely useful, thanks !

Friday 15 March 2013 2:45:37 pm


I have currently developed a beta version of a DebugBundle, however, it is currently not code standards compliant and not documented. A basic summary of it's functionality is:

  • the "dump_vars" function to output variable visibility (similar to the 4.x attribute operator)
  • a "debug" tag (see next item)
  • some basic debug output that will be added to the bottom of the page, will include:
    • redirect the "dump_vars" function output if the "debug" tag is being used
    • output a list of twig files being used with:
      • the number of times used
      • total elapsed time to display each
      • average elapsed time to display

I plan on getting it compliant and placed on over the next week or so. Any feedback would be great.


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from